| 00:02:13 | * | brson quit (Ping timeout: 248 seconds) |
| 00:05:51 | * | darkf joined #nimrod |
| 00:09:42 | * | BitPuffi1 joined #nimrod |
| 00:12:17 | * | BitPuffi1 is now known as BitPuffin |
| 00:34:21 | Discoloda | '' |
| 00:34:24 | Discoloda | ' |
| 00:41:21 | BitPuffin | Still must say that being able to define a || operator that let's you do |a| would be beyond badass |
| 00:48:35 | fowl | what is |a| |
| 00:53:13 | * | filwit joined #nimrod |
| 00:53:45 | filwit | hey guys, i'm trying to modify my fork of Nimrod/devel |
| 00:53:50 | filwit | but not the best at git |
| 00:54:06 | filwit | i want to make sure i'm not changing master. Steps? |
| 00:54:33 | reactormonk | filwit, git checkout devel |
| 00:54:36 | filwit | git pull upstream; git merge upstream/master; git checkout upstream/devel |
| 00:55:08 | filwit | reactormonk: ^ those steps are all ? |
| 00:55:40 | filwit | then when i modify a file, it will be on my own devel branch? |
| 00:55:55 | filwit | i only ask cause of the 'upstream' (it wont let me just checkout 'deve') |
| 00:56:12 | BitPuffin | haha |
| 00:56:13 | reactormonk | hm |
| 00:56:14 | BitPuffin | I know this guy |
| 00:56:15 | filwit | i see a 'origin/master' but everything else is 'upstrea/...' |
| 00:56:16 | BitPuffin | http://www.reddit.com/r/gifs/comments/1w862f/they_wanted_to_shoot_me_making_games_on_local_tv/ |
| 00:56:31 | BitPuffin | Well "internet know" him |
| 00:56:35 | reactormonk | filwit, go ask in #git |
| 00:56:37 | BitPuffin | best gif 2014 |
| 00:56:38 | filwit | BitPuffin: literally just saw that 2 minutes ago, lol |
| 00:56:38 | BitPuffin | srsly |
| 00:56:45 | EXetoC | :p |
| 00:56:51 | filwit | reactormonk: k |
| 00:57:29 | EXetoC | slightly higher WPM than me |
| 00:57:30 | filwit | jesus.. 1000+ folks in #git |
| 00:58:47 | BitPuffin | http://hackertyper.com/ |
| 01:05:54 | BitPuffin | http://youtu.be/u8qgehH3kEQ wow |
| 01:06:08 | filwit | 1000+ people and no one is answering me :( |
| 01:07:14 | BitPuffin | filwit: welcome to irc |
| 01:07:17 | filwit | reactormonk, reason i ask, is cause koch on my devel branch fails (at compiler/types.nim) but the devel branch on the real repo succeeds |
| 01:09:08 | filwit | ah, nevermind, i think there was a merge conflict |
| 01:09:15 | filwit | that's probably the reason |
| 01:09:36 | filwit | how to make the upstream overwrite my local repo? |
| 01:10:03 | filwit | guess i should just google it... |
| 01:23:16 | reactormonk | filwit, delete the local branch, recreate it |
| 01:24:04 | filwit | reactormonk: i'll try that, but someone from #git his helping me now |
| 01:28:34 | fowl | git it super confusing |
| 01:28:47 | fowl | and there are no decent gui clients for it :/ |
| 01:29:25 | filwit | never really used anything else besides SVN, and i much prefer GIT |
| 01:30:33 | filwit | ps. reactormonk: here's an output of some git branch -a, and git log: https://gist.github.com/PhilipWitte/8641866 |
| 01:32:13 | reactormonk | filwit, I'd go for the nuclear option and just git branch -D devel and git checkout -b devel upstream/devel |
| 01:32:47 | BitPuffin | fowl: hg |
| 01:32:49 | filwit | reactormonk: great, thanks |
| 01:32:52 | BitPuffin | and filwit, hg |
| 01:32:58 | filwit | hg? |
| 01:33:26 | BitPuffin | http://mercurial.selenic.com/ |
| 01:33:30 | EXetoC | short for hug |
| 01:33:48 | reactormonk | BitPuffin, kinda dead from what I've heard |
| 01:34:22 | BitPuffin | reactormonk: you've heard wrong but ok |
| 01:34:30 | * | xenagi joined #nimrod |
| 01:34:53 | reactormonk | BitPuffin, kk. Sadly, git has github. So that's gonna stick for a while. |
| 01:35:03 | BitPuffin | reactormonk: true |
| 01:35:12 | BitPuffin | reactormonk: however bb is quite nice |
| 01:35:21 | filwit | only other repo i'd consider is Bazaar |
| 01:35:33 | filwit | but really happy with git so far really |
| 01:35:33 | reactormonk | wasn't that the dead one? ^^ |
| 01:35:35 | EXetoC | "GET /myadmin/scripts/setup.php" lul |
| 01:35:41 | BitPuffin | not as good as gh maybe but still doesn't lack anything I need |
| 01:35:47 | BitPuffin | lol bzr |
| 01:36:03 | reactormonk | Got three seqs, how do I create the product of them? |
| 01:36:05 | filwit | tons of AUR packages use bzr... |
| 01:36:05 | BitPuffin | yeah bzr is get |
| 01:36:13 | BitPuffin | it's ONLY used by canonical |
| 01:36:16 | BitPuffin | and when I say get |
| 01:36:17 | BitPuffin | I mean dead |
| 01:36:24 | filwit | no.. Inkscape |
| 01:36:32 | filwit | some others, i forget now though |
| 01:36:35 | BitPuffin | EXetoC: stop typing stuff that I read while typing |
| 01:36:36 | filwit | i think maybe GIMP |
| 01:36:45 | * | noam joined #nimrod |
| 01:36:58 | BitPuffin | filwit: No don't think so |
| 01:37:08 | BitPuffin | but yeah there is a few |
| 01:37:10 | BitPuffin | but not many |
| 01:37:22 | BitPuffin | kazam or whatever dafuq it's called uses it I believe |
| 01:37:50 | filwit | Blender just switched to Git, so that means Git > All |
| 01:37:59 | filwit | plus Linus wrote it so... |
| 01:38:06 | filwit | unquestionable king |
| 01:39:23 | EXetoC | BitPuffin: ok |
| 01:40:11 | * | Varriount|Mobile quit (Remote host closed the connection) |
| 01:40:27 | * | Varriount|Mobile joined #nimrod |
| 01:41:30 | BitPuffin | EXetoC: deal |
| 01:48:08 | EXetoC | bacon |
| 01:54:49 | BitPuffin | I ate that today |
| 01:54:53 | BitPuffin | or I guess it's yesterday now |
| 02:01:16 | EXetoC | yum |
| 02:01:16 | * | EXetoC quit (Quit: WeeChat 0.4.2) |
| 02:09:56 | * | ddl_smurf joined #nimrod |
| 02:16:46 | filwit | how do i build Nimrod without Koch? |
| 02:17:29 | filwit | compile/nimrod.nim? |
| 02:17:33 | filwit | compiler* |
| 02:17:53 | filwit | so just $ nimrod c compiler/nimrod |
| 02:17:56 | filwit | anything else? |
| 02:18:33 | filwit | nevermind, still fails, wtf.. |
| 02:19:39 | filwit | anyone else getting: compiler/types.nim(454, 33) Error: ')' expected; when trying to build from devel? it doesn't happen on the real repo, but happens on my fork |
| 02:50:42 | * | filwit quit (Quit: Leaving) |
| 02:53:05 | reactormonk | anyone got product code? |
| 03:08:09 | Varriount|Mobile | huh? |
| 03:18:33 | * | aftershave joined #nimrod |
| 03:19:32 | reactormonk | proc product[T](x: openarray[seq[T]]): seq[seq[T]] = |
| 03:24:25 | * | Boscop quit (Read error: Connection reset by peer) |
| 03:29:06 | Varriount | reactormonk: What kind of product? Unordered, no repeats, ? |
| 03:33:28 | * | renesac quit (Ping timeout: 245 seconds) |
| 03:35:53 | * | brson_ quit (Quit: leaving) |
| 03:43:00 | fowl | use sequtils |
| 03:43:53 | Varriount | fowl: Sequtils doesn't have cartesian product, iirc |
| 03:52:22 | xtagon | Does anyone know if there's a good example of how to use execProcess? I'm trying to figure out how to pipe a string to a command, then the stdout of that command to another command. It's easy to do in bash, but I want to do it in Nimrod |
| 04:02:59 | * | BitPuffin quit (Quit: WeeChat 0.4.2) |
| 04:03:21 | * | BitPuffin joined #nimrod |
| 04:03:44 | * | werebutt joined #nimrod |
| 04:03:45 | * | werebutt left #nimrod (#nimrod) |
| 04:08:42 | reactormonk | Varriount, unordered. there's a unique in sequtils, so no repeats is fine. Unordered too. |
| 04:15:17 | * | aftershave quit (Quit: Computer has gone to sleep.) |
| 04:42:10 | * | DAddYE joined #nimrod |
| 04:42:25 | Varriount | reactormonk: If I had the time, I would write up some code, but unfortunately I have to write an essay using vaguely stated directions |
| 04:42:34 | * | renesac joined #nimrod |
| 04:43:41 | Varriount | reactormonk: The basic outline of a variadic cartesian product procedure would be to use a binary product procedure (two nested 'for' loops) on the given elements, accumulating the results. |
| 04:45:23 | Varriount | See this D code for an idea - https://github.com/quickfur/phobos/commit/1b90ce37021de777cc2a6d7d9e32a8625ca4a100 |
| 04:46:40 | * | renesac quit (Ping timeout: 245 seconds) |
| 04:52:53 | reactormonk | Varriount, oh, I like the idea of inline unittests |
| 04:53:41 | Varriount | Huh? |
| 04:53:48 | reactormonk | Varriount, in the file linked ^^ |
| 04:53:56 | reactormonk | https://github.com/quickfur/phobos/blob/1b90ce37021de777cc2a6d7d9e32a8625ca4a100/std/algorithm.d |
| 04:55:18 | Varriount | reactormonk: That's what we we have 'when isMainModule' for. |
| 04:55:35 | reactormonk | Varriount, yup, but that kinda drags it to the end of the file |
| 04:55:52 | Varriount | Or right after the procedure. |
| 04:56:05 | Varriount | The unittests don't have to be in one clump. |
| 04:58:10 | Varriount | reactormonk: If you get a product procedure working right, add it to algorithms.nim and send in a pull request. |
| 04:58:14 | Varriount | Good luck! |
| 04:58:47 | * | renesac joined #nimrod |
| 05:04:42 | * | xenagi quit (Quit: Leaving) |
| 05:25:43 | * | Demos quit (Read error: Connection reset by peer) |
| 05:47:09 | * | isenmann joined #nimrod |
| 06:03:37 | * | bbodi joined #nimrod |
| 06:03:50 | * | xtagon quit (Quit: Leaving) |
| 06:04:54 | * | Varriount|Mobile quit (Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )) |
| 06:08:45 | * | vbtt joined #nimrod |
| 06:09:40 | vbtt | hello |
| 06:16:35 | vbtt | can someone review the last example for type classes here: http://vocalbit.com/posts/exploring-type-classes-in-nimrod.html |
| 06:18:54 | * | vbtt quit (Quit: Page closed) |
| 06:31:23 | * | renesac quit (Ping timeout: 245 seconds) |
| 06:35:09 | * | Mordecai joined #nimrod |
| 06:36:31 | * | psquid quit (Ping timeout: 272 seconds) |
| 06:44:03 | * | renesac joined #nimrod |
| 06:45:55 | * | bbodi quit (Ping timeout: 253 seconds) |
| 07:05:22 | * | Mat3 joined #nimrod |
| 07:05:32 | Mat3 | hi all |
| 07:10:02 | * | vbtt joined #nimrod |
| 07:10:27 | vbtt | hi Mat3 |
| 07:23:34 | Mat3 | hi vbtt |
| 07:36:49 | * | zahary joined #nimrod |
| 07:38:29 | Mat3 | hello zahary |
| 07:38:29 | vbtt | hi zahary |
| 07:39:11 | vbtt | zahary: when you get a chance can you please verify the last example on http://vocalbit.com/posts/exploring-type-classes-in-nimrod.html |
| 07:41:57 | * | DAddYE_ joined #nimrod |
| 07:44:01 | * | DAddYE quit (Ping timeout: 272 seconds) |
| 07:49:20 | zahary | vbtt: sure, the code is correct, but I haven't tried yet to test it / fix it |
| 07:49:29 | zahary | hi Mat3 |
| 07:50:01 | vbtt | zahary: thanks - just want to make sure the code is correct. last time i wrote a rushed example and it was incorrect. |
| 07:52:01 | * | DAddYE_ quit (Remote host closed the connection) |
| 07:52:29 | * | renesac quit (Ping timeout: 240 seconds) |
| 07:54:37 | Mat3 | I'm puzzled again how to implement unions in Nimrod. The reason for this is, using unions in C is useful abstracting endian dependent storage and I can't think of a rational reason for a system-programming language as Nimrod not directly support it - specially as Nimrod compiles to C |
| 07:56:22 | vbtt | Mat3: did you look at object variants? |
| 07:56:34 | vbtt | it's a better version of unions |
| 07:56:57 | vbtt | Mat3: http://nimrod-lang.org/tut2.html#object-variants |
| 07:57:16 | * | aftershave joined #nimrod |
| 07:57:17 | Mat3 | yes, but compiling to unions can't be granted |
| 07:57:53 | vbtt | Mat3: why do you care about the compiled code? |
| 07:58:51 | Mat3 | because low-level programming is endian dependent (and I'm wrote a JIT compiler) |
| 07:59:19 | vbtt | ah i see. will casting not work for you either? |
| 07:59:32 | Mat3 | no |
| 08:01:06 | vbtt | you'll have to ask araq. i'm not sure what c unions will give you that can't be achieved by casting in nimrod. |
| 08:01:09 | Mat3 | my current solution is encapsulating code-storage though an object which explicitly handles endian conversion (but that's an ugly effort compared to C) |
| 08:01:51 | Mat3 | there also exist a module for that purpose |
| 08:02:04 | vbtt | Mat3: that sounds reasonable - the performance should be comparable to c anyway, no? |
| 08:02:18 | vbtt | you only have to define this object once, i hope. |
| 08:02:24 | Mat3 | yes of course |
| 08:03:14 | Araq | Mat3: in theory 'cast' can be used instead of 'union' for everything |
| 08:03:23 | Mat3 | hi Araq |
| 08:03:38 | Araq | in practice it can suck ;-) |
| 08:03:39 | * | DAddYE joined #nimrod |
| 08:04:10 | Araq | so yeah, unions and bit fields will be supported with yet another pragma (yap) |
| 08:04:11 | * | DAddYE quit (Remote host closed the connection) |
| 08:04:17 | * | DAddYE joined #nimrod |
| 08:04:48 | Mat3 | thanks |
| 08:06:02 | * | renesac joined #nimrod |
| 08:06:19 | Mat3 | hi DAddYE and renesac |
| 08:08:28 | vbtt | btw does anyone use aporia? |
| 08:09:48 | Mat3 | Araq: I'm think finishing my documentation today and start working on the Nimrod subset (Ninive sounds a good name for it) |
| 08:10:10 | Araq | ok great |
| 08:10:22 | Araq | vbtt: I use it all the time on both linux and windows ... |
| 08:10:58 | vbtt | Araq: cool. i'll give it a shot then - sounds stable enough. hope it supports other languages.. |
| 08:14:18 | Araq | it does |
| 08:20:36 | vbtt | later, guys |
| 08:20:45 | Mat3 | ciao |
| 08:20:54 | * | vbtt quit (Quit: Page closed) |
| 08:22:45 | Mat3 | in danger repeating me: The lua economy established an effort bringing Lua to system applicage with similar goals to my project: http://www.eluaproject.net/ |
| 08:24:14 | Mat3 | there also exist some projects like that for various Basic dialects and not to forhet C# of course (even ML as I see) |
| 08:24:45 | Mat3 | ^forget |
| 08:25:30 | Mat3 | so the race is started ;) |
| 08:26:00 | Mat3 | (or the race is on ? anyhow) |
| 08:27:27 | Araq | Mat3: that doesn't change the fact that Lua is a pita to debug with its cascading nil values ... |
| 08:28:32 | Araq | tuple[a: bool, b: int16] # 4 bytes in nimrod, now try the same with Lua and you're fighting the language |
| 08:29:03 | Mat3 | I know (somehow Lua fans does not see the relevance of that argument however) |
| 08:29:36 | Araq | fyi I wrote the first version of "pas2nim" in Lua ... :-) |
| 08:30:03 | Araq | somehow the simpler language didn't lead to simpler code ;-) |
| 08:32:07 | Mat3 | I once wrote a specific filter for raw-satellite data in Lua (rewrote that mess in Forth later) |
| 08:32:37 | Mat3 | my experience with Lua is as bad as yours |
| 08:34:17 | Mat3 | anyhow; There exist fine Basic dialects for embedded systems ;) |
| 08:39:18 | * | Mordecai quit (Ping timeout: 245 seconds) |
| 08:39:42 | * | Mordecai joined #nimrod |
| 08:39:49 | Mat3 | hello Mordecai |
| 08:41:17 | * | zahary quit (Quit: Leaving.) |
| 08:43:02 | * | mal`` quit (Read error: Operation timed out) |
| 08:43:31 | * | mal`` joined #nimrod |
| 08:54:12 | * | zahary joined #nimrod |
| 09:03:28 | * | zahary1 joined #nimrod |
| 09:05:41 | * | zahary quit (Ping timeout: 248 seconds) |
| 09:13:04 | * | DAddYE quit (Remote host closed the connection) |
| 09:16:35 | * | zahary1 quit (Ping timeout: 252 seconds) |
| 09:35:15 | * | CarpNet joined #nimrod |
| 09:41:22 | * | silven quit (Remote host closed the connection) |
| 09:44:21 | * | silven joined #nimrod |
| 10:06:57 | * | aftershave quit (Quit: Computer has gone to sleep.) |
| 10:14:08 | * | DAddYE joined #nimrod |
| 10:18:49 | * | DAddYE quit (Ping timeout: 272 seconds) |
| 10:21:22 | * | aftershave joined #nimrod |
| 10:33:41 | * | ics quit (Ping timeout: 248 seconds) |
| 10:35:30 | * | ics joined #nimrod |
| 10:37:29 | * | BitPuffin quit (Ping timeout: 240 seconds) |
| 11:09:08 | Mat3 | ciao |
| 11:09:17 | * | Mat3 quit (Quit: Verlassend) |
| 11:11:32 | * | EXetoC joined #nimrod |
| 11:15:44 | * | DAddYE joined #nimrod |
| 11:16:32 | * | DAddYE_ joined #nimrod |
| 11:20:37 | * | DAddYE quit (Ping timeout: 272 seconds) |
| 11:21:15 | * | DAddYE_ quit (Ping timeout: 272 seconds) |
| 12:45:49 | * | BitPuffin joined #nimrod |
| 12:50:21 | * | BitPuffin quit (Ping timeout: 252 seconds) |
| 12:58:10 | renesac | Araq, is the devel compiler already capable of compiling the Particle Bench with glfw? |
| 12:59:45 | renesac | btw, the case inconsistency in our ParticleBench will bite us in the compressed source size comparison |
| 13:01:35 | * | Mordecai is now known as psquid |
| 13:15:08 | * | [1]Endy joined #nimrod |
| 13:38:17 | * | delian66 joined #nimrod |
| 13:40:08 | EXetoC | renesac: I don't know, but the VM ICE triggered by glfw.nim was fixed recently |
| 13:40:42 | EXetoC | ok N.nim segfaults |
| 13:40:58 | * | _nano quit (Ping timeout: 245 seconds) |
| 13:41:00 | renesac | :/ |
| 13:48:49 | EXetoC | renesac: it does work. I forgot to pull |
| 14:03:11 | * | bbodi joined #nimrod |
| 14:03:17 | bbodi | hi all |
| 14:03:47 | bbodi | I have a simple data structure and a proc, which dont want to be compiled :) |
| 14:04:03 | bbodi | PSelectItem*[T] = ref TSelectItem[T] |
| 14:04:03 | bbodi | TSelectItem*[T] = object |
| 14:04:20 | bbodi | proc drawItem*[T](item: PSelectItem[T]) = |
| 14:04:25 | bbodi | it throws me internal error |
| 14:04:37 | bbodi | with the latest version of the compiler |
| 14:04:54 | bbodi | dou you see any problem with that code? |
| 14:05:07 | bbodi | (TSelectItem contains some trivial fields of course) |
| 14:06:20 | EXetoC | that alone compiles for me and I don't know if anything similar has been reported |
| 14:08:06 | renesac | EXetoC: \o/ |
| 14:08:18 | renesac | then I will move back to nimrod devel head |
| 14:13:54 | bbodi | EXetoC: thanks, then I will investigate further |
| 14:15:26 | bbodi | Yeah, found, its a serious bug! I forgot to put the [T] after the type-name in one of my variable, but the compiler didn't complain about it. I try to reproduce then make an isse about it |
| 14:18:16 | * | darkf quit (Quit: Leaving) |
| 14:35:28 | bbodi | Can we use methods with generic types? |
| 14:36:15 | bbodi | like that: method handleEvent*[T](self: PComboBox[T], event: PEvent) = |
| 14:41:30 | * | io2 joined #nimrod |
| 14:55:52 | Discoloda | is reddit down for you guys? |
| 14:57:28 | OrionPK | nope |
| 15:05:32 | * | vendethiel quit (Remote host closed the connection) |
| 15:05:51 | * | vendethiel joined #nimrod |
| 15:31:34 | OrionPK | hmm reddit on my phone seems to be down thigh |
| 15:31:36 | OrionPK | though |
| 15:31:58 | OrionPK | oh, nevermind |
| 15:42:18 | * | bbodi quit () |
| 15:45:25 | * | io2 quit (Ping timeout: 245 seconds) |
| 15:46:04 | renesac | reddit is probably unstable |
| 16:03:02 | Discoloda | im thinking websites that use the amazon cloud was/is unstable |
| 16:09:33 | * | BitPuffin joined #nimrod |
| 16:21:42 | * | io2 joined #nimrod |
| 16:22:58 | * | zahary joined #nimrod |
| 16:27:12 | * | Mat3 joined #nimrod |
| 16:27:31 | Mat3 | hi all |
| 16:31:55 | renesac | filwit: I'm having the same error trying to compile nimrod devel from my fork |
| 16:32:10 | renesac | did you get any clue of what was wrong? |
| 16:33:05 | * | Mat3 is now known as Mat3-bbl |
| 16:35:56 | * | Mordecai joined #nimrod |
| 16:37:23 | * | psquid quit (Disconnected by services) |
| 16:37:25 | * | Mordecai is now known as psquid |
| 16:43:02 | * | renesac is now known as renesac|away |
| 16:55:14 | * | nueva joined #nimrod |
| 16:59:51 | * | zahary quit (Quit: Leaving.) |
| 17:06:05 | nueva | EXetoC: here is a patch for current devel HEAD to fix errors when compiling with -d:useFFI http://pastebin.com/zCfcNJxe |
| 17:06:54 | nueva | *when compiling compiler |
| 17:14:18 | * | Demos joined #nimrod |
| 17:16:25 | nueva | Demos: do you have sources of VisualStudio project support available somewhere? |
| 17:17:19 | nueva | can somebody provide an example of idetools command usage? |
| 17:19:14 | * | Varriount|Mobile joined #nimrod |
| 17:20:44 | Varriount|Mobile | Araq: I think there is a syntax error present in one of the branches that is preventing users from building Nimrod. See the most recent issue on GitHub |
| 17:22:16 | * | tdc joined #nimrod |
| 17:25:33 | * | BitPuffin quit (Ping timeout: 245 seconds) |
| 17:41:10 | renesac|away | Varriount|Mobile, filwit: putting some parenthesis on the pointed spot fixed it, and I managed to compile it |
| 17:43:04 | Demos | yay! |
| 17:43:07 | Demos | I got the same problem |
| 17:43:12 | renesac|away | what a difference, 48 seconds to bootstrap compiling itself 3 times vs 43 minutes for compiling from the provided cpp sources in rust |
| 17:43:35 | Demos | is rust written in cpp? |
| 17:43:39 | renesac|away | I will report on the github issue |
| 17:43:45 | renesac|away | no, I think it is written in rust |
| 17:44:01 | renesac|away | but the tar.gz file I download was full of cpp sources |
| 17:44:28 | Demos | wierd. maybe the nimrod bootstrap process is better aobut dependencies |
| 17:44:47 | renesac|away | or maybe because it compiles to c instead of cpp... |
| 17:44:55 | dom96 | renesac|away: What did you turn the line into? internalAssert(false) ? |
| 17:45:12 | * | renesac|away haven't tried the cpp mode from nimrod |
| 17:45:19 | renesac|away | dom96, wait a minute |
| 17:46:03 | renesac|away | else: (internalAssert(false); "") |
| 17:46:12 | renesac|away | this did the trick |
| 17:46:36 | dom96 | that's what I thought |
| 17:47:10 | renesac|away | maybe the devel compiler can compile that w/o parenthesis, but the master can't |
| 17:47:27 | dom96 | indeed, or a previous version of devel. |
| 17:48:08 | * | renesac|away is now known as renesac |
| 17:48:12 | NimBot | Araq/Nimrod devel c3e531b Dominik Picheta [+0 ±1 -0]: Fixes #848. |
| 17:48:14 | Demos | renesac|away: c is not really faster to compile than cpp aside from the fact that cpp shares c's compalation model and when combined with some of cpp's features that can force more files into the header |
| 17:49:14 | Demos | also, I just submitted a pr to add my alpm wrapper to babel... just so someone knows |
| 17:49:59 | Demos | 43mins seems excessive, were you using MSVC 11 or something? |
| 17:50:06 | Discoloda | Demos: its the template instantiation, each translation unit gets new instances of templated classes/functions |
| 17:50:28 | Demos | Discoloda: I mean sure. But I think more problematic is just the way headers work |
| 17:50:52 | Demos | combined with the need to put templates in headers can cause a snowball effect where tons of code is included in each TU |
| 17:51:10 | NimBot | nimrod-code/packages master 10855fb charlie [+0 ±1 -0]: added libalpm package |
| 17:51:10 | NimBot | nimrod-code/packages master c0e3bfd Dominik Picheta [+0 ±1 -0]: Merge pull request #45 from barcharcraz/master... 2 more lines |
| 17:51:12 | Discoloda | well, that is why cpp usually takes longer than c |
| 17:51:24 | Demos | true |
| 17:51:51 | Demos | and because C projects tend to be lower level and have less dependencies (LOOKING AT YOU BOOST) |
| 17:52:23 | Demos | I have worked on a c++ project where just including one header from a certain library would make the TU take 20sec to compile |
| 17:52:40 | Discoloda | lol |
| 17:52:43 | renesac | Demos, I'm using g++ and executing the make |
| 17:52:56 | Demos | but yeah. Nimrod compile times are quite nice. I am a little suprised the rust is so sluggish |
| 17:52:58 | renesac | I don't know why it took so long |
| 17:53:21 | renesac | note that I didn't compile any rust code, the rust compiler itself can be fast |
| 17:53:28 | Demos | right |
| 17:53:39 | renesac | but building the compiler from the tar.gz provided was very slow... |
| 17:54:06 | dom96 | Doesn't Rust have to build its own version of LLVM or something? |
| 17:54:24 | Demos | hm, if it did that would be the problem |
| 17:54:44 | dom96 | I recall reading somewhere that that is the reason why it is so slow. |
| 17:54:54 | Demos | but even gcc is faster than 40mins (esp if you exclude like fortran, ada and xcompile) |
| 17:55:48 | Demos | andhow nimrod's bootstrap process is better than pie and it makes us happy |
| 17:56:28 | * | icebattle joined #nimrod |
| 18:00:20 | renesac | :) |
| 18:01:25 | * | Demos quit (Ping timeout: 272 seconds) |
| 18:04:20 | * | bbodi joined #nimrod |
| 18:04:54 | reactormonk | compiling to C has a few distinctive advantages |
| 18:06:32 | * | BitPuffin joined #nimrod |
| 18:11:51 | * | DAddYE joined #nimrod |
| 18:16:10 | * | Varriount|Mobile quit (Remote host closed the connection) |
| 18:18:52 | NimBot | Araq/Nimrod devel 50e7129 Dominik Picheta [+1 ±2 -1]: Finished logging module. |
| 18:27:11 | * | brson joined #nimrod |
| 18:32:32 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 18:38:18 | * | ics joined #nimrod |
| 18:46:16 | reactormonk | if someone is interested in writing a product for the algorithm.nim, here are the tests: http://dpaste.com/1572533/ |
| 18:47:09 | reactormonk | http://dpaste.com/1572542/ actually. |
| 19:09:28 | * | aftersha_ joined #nimrod |
| 19:09:44 | * | aftershave quit (Quit: Computer has gone to sleep.) |
| 19:26:22 | * | io2 quit (Read error: Operation timed out) |
| 19:36:11 | * | BitPuffin quit (Ping timeout: 260 seconds) |
| 19:42:22 | * | reactormonk quit (Quit: WeeChat 0.4.1) |
| 19:47:44 | * | brson quit (Quit: leaving) |
| 19:48:00 | * | brson joined #nimrod |
| 19:57:10 | * | xtagon joined #nimrod |
| 19:59:01 | * | Mat3-bbl is now known as Mat3 |
| 20:12:15 | * | io2 joined #nimrod |
| 20:13:18 | * | Mat3 do not know why new languages like Rust features a C oriented syntax |
| 20:14:22 | Varriount | Mat3: Because the languages are designed for masochists |
| 20:14:42 | Mat3 | hello Varriount |
| 20:15:47 | EXetoC | familiarity IIRC |
| 20:16:19 | EXetoC | >.> |
| 20:17:00 | Mat3 | hi EXetoC |
| 20:25:12 | * | Icefoz joined #nimrod |
| 20:30:33 | EXetoC | lo |
| 20:31:20 | * | Icefoz quit (Quit: leaving) |
| 20:36:01 | renesac | Mat3, in rust they argued about conceptual parser simplicity |
| 20:36:11 | renesac | all could be condensed in a simple line to be compiled |
| 20:37:41 | renesac | and there are many JS programmers that hates the idea of "automatic semicolon insertion" |
| 20:39:45 | * | bbodi quit (Ping timeout: 272 seconds) |
| 20:39:49 | renesac | and probably never learned python's way of getting rid of semicolons while mantaining flexibilty of multiline expressions |
| 20:40:34 | renesac | they prefer paying for this flexibilty every line, instead of putting a parenthesis in the rare lines when they need |
| 20:41:07 | renesac | or not even that, because usually you already have some handy break point |
| 20:41:42 | renesac | and they think about method chaining, not functions with multiple optional named parameters |
| 20:41:50 | Mat3 | Forth is an example for parser simplicity: Only white spaces needed + RPN |
| 20:43:08 | renesac | the latter is much easier to split in multiple lines w/o the need of any superfulous extra characters |
| 20:43:54 | renesac | but the former is the Java/C++ way |
| 20:46:57 | Mat3 | hmm, I think the Fortran syntax for example is far more readable and can be parsed with comparable effort |
| 20:55:36 | * | Discoloda left #nimrod (#nimrod) |
| 20:56:28 | Mat3 | anyhow, there seem to like curly braces and related noise, so its ok |
| 20:56:47 | Mat3 | (for them) |
| 20:57:59 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 20:58:26 | * | [1]Endy quit (Ping timeout: 264 seconds) |
| 21:01:37 | renesac | well, curly braces are redundant, and this redundancy may be useful when for some reason you lost the identation |
| 21:02:02 | renesac | you can then reconstruct the program structure and identation from the curly braces |
| 21:02:38 | Araq | yeah but if the braces and the indentation disagree, whom do you trust? ;-) |
| 21:02:40 | renesac | the common cited situations are: code pasted as plain text in e-mails and comments, copy-paste in code refactoring |
| 21:02:44 | * | XAMPP joined #nimrod |
| 21:02:44 | * | XAMPP quit (Changing host) |
| 21:02:44 | * | XAMPP joined #nimrod |
| 21:03:17 | renesac | the first one can be worked around pointing to code hosted in proper places |
| 21:03:31 | * | Discoloda joined #nimrod |
| 21:03:52 | renesac | the second one I never understood because I never worked with a IDE that fixed those things up for me |
| 21:04:24 | renesac | or better, I never worked enough time to bother learning all the ins-outs of the IDE |
| 21:04:56 | Araq | renesac: it's however *very* simple to design a syntax that neither requires ';' nor newlines |
| 21:05:10 | Araq | it does require {} or 'end' though |
| 21:05:18 | renesac | but selecting the copied code and tabbing/un-tabbing around aways looked simple for me |
| 21:05:34 | renesac | it would be more difficult if I had also to fix {} |
| 21:06:08 | renesac | Araq, any language that way? |
| 21:06:27 | renesac | well, I bet there are many |
| 21:06:29 | Mat3 | doesn't one advantage of structured languages where once there independence from syntactical elements like blocks ? |
| 21:06:41 | renesac | ? |
| 21:07:22 | Mat3 | why does one need curly braces in loops where a simple end statement would be sufficient ? |
| 21:07:51 | Araq | renesac: in fact only some dialects of basic come to mind |
| 21:07:52 | renesac | to not type the end statement |
| 21:09:06 | Araq | oberon iirc doesn't require semicolons at all |
| 21:09:18 | renesac | well, brainfuck can be written all in one line, and dont't need newlines nor ; |
| 21:09:18 | Araq | but it never occured to wirth they are not necessary |
| 21:09:19 | renesac | :P |
| 21:09:23 | Mat3 | DO i = n, someCall (x) ... endDO (Fortran) |
| 21:09:43 | Mat3 | also no visible line terminator needed |
| 21:09:48 | Mat3 | at all I mean |
| 21:09:50 | renesac | ruby and lua are also this style |
| 21:09:54 | renesac | I find it kinda ugly |
| 21:09:58 | renesac | and lolcode |
| 21:10:26 | renesac | I much prefer indentation defined blocks |
| 21:11:14 | Mat3 | I think it's more readable because of a syntax holding no renundant information (which I call noise) |
| 21:11:38 | renesac | Mat3: hopefully there is correct identation, so it is redundant too |
| 21:12:44 | Mat3 | in Fortran (beside archaic Fortran 77) the parser does not depend on identation at all |
| 21:13:09 | Mat3 | only white-space sperated tokens |
| 21:13:14 | Mat3 | ^seperated |
| 21:13:22 | renesac | yeah, that is true for (almost?) all languages with this kind of redundancy |
| 21:13:50 | renesac | they thus allow misleading identation, as araq said |
| 21:15:02 | renesac | I don't like when people say "white-space sensitive", because it sounds like "invisible-space" |
| 21:15:32 | renesac | when the things it depends on are very visible from the non-white characters that must be around the white-space |
| 21:15:53 | Mat3 | it's even true for APL: (2=0 +.= T o.|T) / T←ιN |
| 21:16:30 | renesac | and almost all languages depends on one type or other of white space, simple space between tokens being the most common |
| 21:16:37 | * | vbtt joined #nimrod |
| 21:16:42 | Araq | yup |
| 21:16:50 | Mat3 | because some seperation must be exist |
| 21:16:52 | renesac | Mat3, IIRC there was a 70's language that didn't care about spaces |
| 21:17:12 | Araq | and if it doesn't, it's weird too: while (n-->0) ... |
| 21:17:44 | vbtt | you can say 'compulsory indentation' instead of 'whitespace sensitive' |
| 21:17:59 | vbtt | (as opposed to 'compulsory braces') |
| 21:18:02 | renesac | I usually say "identation sensitive" or "identation defined" |
| 21:18:08 | Araq | you can also say "layout based parsing" |
| 21:18:27 | fowl | ruby is whitespace sensitive, "method &foo" is different from "method&foo" and "method & foo" |
| 21:19:08 | renesac | fowl: space between identifiers and operators |
| 21:19:12 | renesac | ^^" |
| 21:19:15 | Mat3 | FORi=1TO1000STEP2:PRINTi:NEXTi (hurrah! it work's) |
| 21:19:33 | EXetoC | nice |
| 21:19:40 | fowl | and if you give up paren-less function calls you dont need semicolons |
| 21:19:58 | fowl | echo(foo)x.blah() |
| 21:20:14 | vbtt | i dont like paren-less function calls fwiw. |
| 21:20:31 | renesac | [19:04:56] <Araq> renesac: it's however *very* simple to design a syntax that neither requires ';' nor newlines <-- how we could forget LISP? |
| 21:20:57 | renesac | parenthesis, parenthesis everywhere! |
| 21:20:59 | Araq | renesac: Lisp is in its own league, that's why |
| 21:21:34 | Mat3 | (setq y '(defun multi (x) (* x x))) |
| 21:22:05 | Araq | vbtt: paren-less function calls ftw |
| 21:22:17 | Araq | () are annoying |
| 21:23:39 | Mat3 | SET y TO multi :x x * x END |
| 21:23:49 | Mat3 | (Logo) |
| 21:26:37 | Mat3 | anyhow: I feel most curly-bracers would be quite happy with lisp if the braces would be replaced with curly-braces ;) |
| 21:28:35 | renesac | I'm checking the new paren-less nimrod function calls |
| 21:29:10 | Mat3 | oh, is there a new compiler version out ? |
| 21:29:11 | renesac | I'm trying to get a "adding line to a single line C if" kind of pitfall |
| 21:29:31 | renesac | Mat3, I'm compiling the devel head from github |
| 21:30:03 | Mat3 | ok, I will wait for for the next stable version |
| 21:30:05 | renesac | but so far nimrod isn't letting me make function calls that when extended with a second argument become wrong |
| 21:30:18 | renesac | that is good |
| 21:30:40 | vbtt | renesac:what's the new function call syntax? |
| 21:30:59 | renesac | Araq can explain better than me |
| 21:31:22 | renesac | or maybe link to the place where it is explained |
| 21:32:19 | vbtt | (I thought nimrod already had that) |
| 21:32:58 | NimBot | nimrod-code/nimbuild master 22d158e Dominik Picheta [+0 ±1 -0]: Fixed dummyhub crashing on accept. |
| 21:33:03 | Araq | vbtt: nimrod only had it for statements, but I extended it to expressions |
| 21:33:21 | Mat3 | ncie ! |
| 21:33:28 | Mat3 | sorry, nice ! |
| 21:33:53 | Araq | echo foo bar |
| 21:33:55 | Araq | is |
| 21:33:59 | Araq | echo(foo(bar)) |
| 21:34:15 | Araq | echo foo bar, baz |
| 21:34:17 | Araq | is |
| 21:34:23 | Araq | echo foo(bar, baz) |
| 21:34:42 | renesac | Araq: you already checked/thought in the kind of pitfall I'm trying to trigger? |
| 21:35:01 | OrionPK | pretty soon i'll be able to just copy paste well formatted english and compile it via nimrod |
| 21:35:30 | vbtt | i see |
| 21:35:37 | Mat3 | get some sleep, ciao |
| 21:35:42 | Araq | renesac: not sure but I added tests/parser/tcommand_as_expr.nim |
| 21:35:59 | * | Mat3 quit (Quit: Verlassend) |
| 21:37:16 | vbtt | a b c, d |
| 21:37:22 | vbtt | a(b(c,d)) ? |
| 21:37:23 | vbtt | or |
| 21:37:31 | vbtt | a(b(c), d) ? |
| 21:38:07 | Araq | the former of course |
| 21:38:09 | renesac | right, already found one questionable situation: |
| 21:38:10 | renesac | https://gist.github.com/ReneSac/a638e1f9d3da866e1f55 |
| 21:38:15 | renesac | this is kinda confusing |
| 21:38:29 | renesac | but of course, is not a bug |
| 21:38:40 | * | tdc quit (Quit: Leaving) |
| 21:39:59 | Araq | renesac: initially I wanted to disallow that but found it hard to do with the current grammar :P |
| 21:40:43 | Araq | most important use case is the upcoming 'await' and 'spawn' calls which really need |
| 21:41:01 | Araq | let foo = spawn bar(a, b) |
| 21:41:14 | vbtt | why not just make them keywords? they're special enough. |
| 21:41:18 | renesac | the problem is that when you first wrote that code, the 'optarg' proc didn't had an optional argument |
| 21:41:27 | renesac | and your code printed both fine |
| 21:41:53 | Araq | renesac: that's a very good point |
| 21:41:57 | renesac | and then, by simply someone adding that optional argument in a library function you used, you have a bug |
| 21:42:14 | vbtt | good catch! |
| 21:42:36 | Araq | renesac: yeah makes me reconsider my design |
| 21:42:43 | * | renesac was smelling something fish, glad I could capture it |
| 21:43:09 | vbtt | let foo = spawn(bar a, b) |
| 21:43:10 | Araq | vbtt: the point is to implement 'await' as a macro though |
| 21:43:16 | renesac | *fishy |
| 21:43:17 | vbtt | that will work too.. |
| 21:44:08 | vbtt | hm, perhaps only macros can be called without parens. makes them special at least. |
| 21:44:50 | Araq | vbtt: that doesn't help anything and violates a core design rule of nimrod |
| 21:45:07 | vbtt | which rule? |
| 21:45:18 | Araq | which is to consiously decouple the syntax from the semantics |
| 21:46:07 | Araq | multiple call syntaxes and multiple routine kinds (template, proc etc.) but you can use any call syntax for any routine |
| 21:46:17 | EXetoC | dom96: is {.nimcall.} in jester.nim an optimization? I doubt it makes a noticeable difference. replacing the two instances with {.closure.} fixes my issue |
| 21:46:28 | vbtt | iow, it's a PSL (programmer specific language) |
| 21:46:54 | vbtt | what's wrong with async(foo(a, b)) ? |
| 21:47:00 | Araq | because it's pretty Lisp-y under the hood ;-) |
| 21:47:48 | Araq | also operator overloading and getters and setters all suggest that's what a language should do :-) |
| 21:47:55 | dom96 | EXetoC: What's your issue? |
| 21:48:18 | EXetoC | dom96: that a closure is required in my case |
| 21:48:23 | Araq | vbtt: too many () and not consistent with 'return' etc. |
| 21:48:34 | dom96 | EXetoC: Why would it be? |
| 21:48:54 | dom96 | EXetoC: Is this you trying to have a 'get "/":' inside a proc? |
| 21:49:03 | EXetoC | dom96: yes |
| 21:49:27 | dom96 | EXetoC: Please report it as an issue. |
| 21:49:45 | dom96 | I will take a look at it when I have more time. |
| 21:50:15 | EXetoC | dom96: PR sent |
| 21:50:35 | Araq | renesac: your pitfall is wrong, I think |
| 21:50:36 | vbtt | really? what's the setter syntax? (can't remember it cause it's not symmetrical to getter syntax) |
| 21:50:49 | Araq | proc `foo=` |
| 21:53:03 | Araq | renesac: parsing doesn't look at proc definitions |
| 21:53:07 | Araq | so this: |
| 21:53:14 | EXetoC | will echo"x", "y" remain disallowed? |
| 21:53:21 | Araq | proc optarg(x:int):int = x |
| 21:53:22 | Araq | proc singlearg(x:int):int = 20*x |
| 21:53:24 | Araq | echo optarg 1, singlearg 2 |
| 21:53:27 | Araq | fails |
| 21:53:37 | Araq | as it passes 2 arguments to 'optarg' |
| 21:54:00 | vbtt | Araq:why does it need to be consistent with 'return'? it's not a special control-flow statement, is it? ;) |
| 21:54:48 | Araq | weill 'await' is sugar for 'yield' so arguably it is a control-flow statement |
| 21:55:15 | vbtt | just curious - is 'if' implemented as a macro? |
| 21:55:20 | Araq | renesac: you need to try harder :P |
| 21:55:30 | Araq | vbtt: no |
| 21:55:59 | Araq | in fact, keywords are the ugliest part in nimrod's syntactical design |
| 21:56:11 | Araq | but they are also very hard to get rid of |
| 21:57:33 | vbtt | i guess i understand the design philosophy better.. |
| 21:57:40 | vbtt | and disagree with it. |
| 21:58:38 | Araq | I can imagine |
| 21:59:03 | Araq | but what's the alternative? IMHO there is none |
| 22:00:10 | vbtt | there are many alternatives of course. but they follow a different design philosophy. |
| 22:00:13 | Araq | disallowing operator overloading is no solution, it leads to barbaric code where a[i] works for arrays but nothing else. good luck trying to write generic code with that. |
| 22:00:52 | vbtt | i like some code elements to be 'special'. e.g. function and type definitions, control structures, operators. |
| 22:01:04 | Araq | in C# I don't know whether it's a.prop() or a.prop ... |
| 22:01:21 | vbtt | you can have overloading of course - by just overloading special methods. |
| 22:01:21 | Araq | etc. there is no alternative. |
| 22:01:38 | Araq | that's just stupid. |
| 22:01:43 | vbtt | in nimrod I dont know how to get a reference to a function, without calling it. |
| 22:01:55 | Araq | is % '__percent__' or '__format__' ? |
| 22:02:11 | Araq | is + '__add___ or '__plus__'? |
| 22:02:18 | Araq | and what is += then? |
| 22:02:25 | vbtt | you could just follow convention - use the character name (not semantic operation) |
| 22:02:46 | Araq | vbtt: wrong, you do know if you get a reference or not |
| 22:02:57 | vbtt | but having too may operators is also not a good thing in my book. haskell is so confusing. |
| 22:03:09 | vbtt | everything has a new operator (because it's possible) |
| 22:03:32 | Araq | *shrug* that's a problem of the programming culture |
| 22:03:37 | vbtt | a = f # in python if f is a function a is the same function |
| 22:03:44 | vbtt | in nimrod? f is called, I supposed? |
| 22:03:49 | Araq | nope |
| 22:03:55 | Araq | a = f x # call |
| 22:04:03 | Araq | a = f # no call |
| 22:04:08 | Araq | a = x.f # call |
| 22:04:51 | vbtt | why no shortcut for a = f() ? |
| 22:05:02 | vbtt | nimrod just special cases something else. |
| 22:05:08 | * | psquid quit (Ping timeout: 245 seconds) |
| 22:05:09 | Araq | because first class functions are more important |
| 22:05:22 | vbtt | btw, type T = object x: String t = T() t.x # is it x(t) or the field? |
| 22:05:39 | Araq | the field |
| 22:06:12 | * | psquid joined #nimrod |
| 22:06:12 | Discoloda | stupid idea but, why not .f == f() |
| 22:06:13 | vbtt | all i'm saying are such things are not obvious to me. |
| 22:06:18 | Araq | why should nulladic function application be done without ()? it's rare and would be confusing :P |
| 22:06:27 | vbtt | but consistent. |
| 22:06:32 | vbtt | a = f x, y, z |
| 22:06:34 | vbtt | a = f x, y |
| 22:06:36 | vbtt | a = f x |
| 22:06:37 | vbtt | a = f |
| 22:07:01 | Araq | *shrug* so what, first class functions are more important |
| 22:07:02 | vbtt | last one is special case. i understand special cases are necessary. i'm just pointing out you cant get away from it. |
| 22:09:13 | nueva | for the syntax discussion: there is indentation-based syntax for lisp isomorphic to sexps http://readable.sf.net |
| 22:11:00 | Araq | nueva: already know it, but thanks |
| 22:11:50 | Araq | Discoloda: leading '.' creates lots of new problems |
| 22:13:12 | nueva | Araq: you know everything in PL sphere, I already understood it (no offence assumed). still it might be interesting to others. |
| 22:14:31 | Araq | vbtt: they might not be obvious but they can be learned and afaict don't create nasty surprises |
| 22:15:03 | Araq | the exception is the fact that we have too few whitespace dependent parts ;-) |
| 22:15:21 | Araq | echo $foo |
| 22:15:23 | Araq | is parsed as |
| 22:15:29 | Araq | echo $ foo |
| 22:15:37 | Araq | and not as echo($foo) |
| 22:15:49 | Araq | but I plan to fix that too ;-) |
| 22:17:47 | OrionPK | yay! |
| 22:18:00 | OrionPK | the echo $foo always gets me |
| 22:18:35 | EXetoC | a terminal emulator depending on a physics engine? interesting |
| 22:18:40 | OrionPK | optimize for optimal cuddliness |
| 22:18:59 | vbtt | what does echo $ foo mean? (with parenthesis please) |
| 22:19:15 | vbtt | it means echo($(foo)) to me in the new syntax. |
| 22:19:16 | OrionPK | echo(`$`(foo)) presumably |
| 22:19:30 | vbtt | and what does echo($foo) mean? |
| 22:19:38 | OrionPK | $ is 'to string' |
| 22:19:40 | EXetoC | same? |
| 22:20:17 | vbtt | right lets say $ is just the function name. |
| 22:20:25 | Araq | echo $ foo = (echo) $ (foo) |
| 22:20:35 | Araq | aka binary operator invokation |
| 22:21:05 | Araq | and no, $ is not a function name, but an operator, `$` would simply be a function name |
| 22:21:22 | vbtt | ah, ok. |
| 22:22:07 | Araq | I had a cool article explaining all this, but dr Dobbs shortened it |
| 22:22:25 | Araq | so now the original article is a chaptel in my book :P |
| 22:22:30 | Araq | *chapter |
| 22:22:37 | vbtt | book? |
| 22:22:46 | vbtt | do you mean manual? |
| 22:22:54 | Araq | no, like a book |
| 22:23:02 | Araq | with printed pages and stuff |
| 22:23:26 | vbtt | hopefully it'll be available in digital format. |
| 22:23:28 | nueva | how can I totally define compiler suite from command line --cc:g++ --g++.exe=/path/to/g++ ? what else Nimrod requires? |
| 22:23:40 | renesac | "vanity publisher" or someone interested by your language? |
| 22:24:11 | vbtt | Araq: what's the scope of the book? |
| 22:24:21 | renesac | and Araq: right, I will try harder ;) |
| 22:24:26 | * | ddl_smurf quit (Quit: ddl_smurf) |
| 22:25:27 | Araq | nueva: just edit the config instead |
| 22:25:33 | Araq | and it's gpp not g++ |
| 22:25:34 | vbtt | btw, the new syntax means (f x) is the same as f(x), correct? |
| 22:25:57 | Araq | vbtt: in some cases, yes |
| 22:26:08 | vbtt | a = f(x) |
| 22:26:10 | nueva | Araq: yeah, I know about config, I want to avoid it. so '+' is an invalid character in option name? |
| 22:26:10 | vbtt | a = (f x) |
| 22:26:32 | vbtt | a = (f(x), g(y)) |
| 22:26:44 | vbtt | a = ((f x), (g y)) |
| 22:27:04 | vbtt | but NOT: a = (f x, g y) # == (f(x, g(y)) |
| 22:27:12 | vbtt | i think i understand. |
| 22:27:14 | nueva | thanks, replacing + with letter helped |
| 22:28:16 | vbtt | getting more like lisp, hehe. |
| 22:28:21 | vbtt | reminds one of that quote. |
| 22:28:31 | Araq | yeah indeed |
| 22:29:27 | * | io2 quit () |
| 22:31:51 | vbtt | with so many options, which one does nimrod pretty pick? |
| 22:32:43 | Araq | nimrod pretty doesn't transform call syntaxes |
| 22:33:10 | Araq | in fact, currently is only makes stuff case consistent and warns about identifiers not adhering to the style guide |
| 22:33:26 | vbtt | ok |
| 22:33:58 | Araq | also your question implies that the different syntaxes would be better one instead |
| 22:34:19 | vbtt | well for operators there is a better one. |
| 22:34:25 | vbtt | (infix) |
| 22:34:30 | vbtt | but yeah, i get what you are saying. |
| 22:36:16 | Araq | echo x.len, y.len, sum(a, b, c) |
| 22:36:18 | nueva | --clib:zlib turns into -l/absolute/path/to/nimrod/compiled/module/directory/zlib. unintitive, I've expected just -lzlib. but I guess --passL is for me then |
| 22:36:34 | Araq | is not better written as: |
| 22:36:47 | Araq | echo(len(x), len(y), sum(a, b, c)) |
| 22:37:12 | Araq | it's exactly this consistency that makes Lisp so hard to work with IMO |
| 22:38:21 | vbtt | I agree with you about lisp. |
| 22:38:37 | vbtt | however, you *can* write it as your second example. |
| 22:38:46 | vbtt | i can't define echo to be only used without parens. |
| 22:39:19 | Araq | yes, that's a different *point* of the language |
| 22:40:17 | Araq | definitions should as far as reasonable not dictate the usage |
| 22:40:50 | Araq | otherwise you get C#'s lovely x.foo vs. x.foo() |
| 22:43:38 | vbtt | what's the issue with x.foo vs x.foo() ? |
| 22:43:43 | Araq | (is it a.Length() or a.Length or a.Count() or a.Count? why do I have to care about it again?) |
| 22:44:15 | vbtt | i see. |
| 22:44:46 | vbtt | your'e looking at it from a usage point of view (how do i ...?) |
| 22:44:59 | Araq | not really |
| 22:45:05 | vbtt | i'm looking at it from a readability point of view (what does this do..?) |
| 22:45:48 | Araq | I know even a.Count() is an O(1) operation and the JIT will inline it |
| 22:45:59 | Araq | so what's the point? let me write a.Count instead |
| 22:46:24 | Araq | what kind of readability are you talking about? |
| 22:46:40 | Araq | a.Count is a property access and a.Count() a method call? yeah very interesting |
| 22:47:00 | Araq | how does it help anybody reading the code? |
| 22:47:22 | Araq | you might as well encode the line number of the defintion at the callsite instead |
| 22:47:24 | * | filwit joined #nimrod |
| 22:48:30 | Araq | and pretend it improves "readability", because it encodes some piece of information |
| 22:48:42 | vbtt | it's always consistent, that's all. |
| 22:51:28 | filwit | well i logged on to ask how to fix my fork of devel, but just pulled and now it's working. great |
| 22:51:34 | renesac | playing with the new function call syntax, I found the method call syntax very useful when you don't want parenthesis: |
| 22:51:35 | filwit | on to trying to fix a bug |
| 22:51:45 | vbtt | nimrod lets you write functions in many forms and people will write them in all its forms. |
| 22:52:03 | vbtt | perhaps that flxibility is your goal. |
| 22:52:15 | filwit | renesac: new function call syntax? |
| 22:52:24 | Araq | and that's perfectly fine with me as it doesn't let people use reflection ;-) |
| 22:52:38 | renesac | 'echo 1.optarg, singlearg 2' will not be affected if optarg has or not an optional argument while 'echo optarg 1, singlearg 2' |
| 22:52:54 | vbtt | didn't get the reflection comment. |
| 22:53:10 | renesac | will print different things wether optarg has or not an optional argument |
| 22:53:25 | renesac | I find the first behaviour better |
| 22:53:48 | Araq | renesac: I think you're wrong |
| 22:54:29 | Araq | vbtt: reflection really produces unmaintainable code, not f(x) vs. (f x) |
| 22:54:30 | renesac | indeed i'M wrong again |
| 22:54:55 | Araq | renesac: the parser never looks at the definitions as it uses no symbol table |
| 22:55:22 | Araq | it's always parsed the same way, no matter how optarg singearg are defined |
| 22:55:23 | renesac | Araq: reflection also produces huge binaries, see Qt5 and their 25mb mobile apps... |
| 22:55:59 | vbtt | Araq:perhaps. i'll have to write more nimrod code to judge. |
| 22:57:01 | Araq | vbtt: it's syntax vs semantics. the semantics are *very* static and so nimrod code is much easier to follow than Golang code |
| 22:57:28 | Araq | but I expect it will take another decade for programmers to realize this |
| 22:57:49 | Araq | as syntax is all they can see |
| 22:58:09 | renesac | Araq, you need to write more blog posts |
| 22:58:29 | renesac | explaining that, for example |
| 23:00:05 | vbtt | Araq: I get your comment about decoupling syntax vs semantics. stuff like that should be on a special page on the website. |
| 23:00:27 | vbtt | nimrod's design philosphy or something. just a blurb. |
| 23:00:50 | Araq | very well, as I said, I already have the chapter |
| 23:00:55 | Araq | can make a blog post out of it |
| 23:02:11 | vbtt | that would be great. |
| 23:02:13 | renesac | Araq, what I meant earlier: https://gist.github.com/ReneSac/a638e1f9d3da866e1f55 |
| 23:02:24 | renesac | they behave a little different |
| 23:02:39 | renesac | and I like the second behaviour better |
| 23:03:56 | renesac | though I'm sure I will find some use for the first form |
| 23:04:06 | renesac | but I think it is less readable |
| 23:04:08 | Araq | weak binding for ',' is strange though |
| 23:04:25 | Araq | it's like attaching 'else' to the outermost 'if' |
| 23:05:02 | renesac | what is the operator precedence of functions now? |
| 23:05:36 | renesac | it fits in that precedence table in the manual? |
| 23:06:50 | Araq | the precedence table is unaffected |
| 23:07:11 | Araq | but doesn't explicitly list ordinary function application |
| 23:07:21 | Araq | because it's "intuitive" :P |
| 23:09:35 | filwit | Araq: trying to fix a compiler bug on sigmatch:897 where a.sons[0] is being returned but a.sonsLen == 0. I'm not sure what to do at this point. (aka, this effects procs which have a T:typedesc[Foo] as first param). any hints on what I should return? |
| 23:10:26 | filwit | guess that's not much to go on |
| 23:10:52 | filwit | i guess i need to understand the structures a bit more really |
| 23:10:57 | Araq | my line 897 is different from your line |
| 23:11:09 | Araq | are you on devel? |
| 23:11:12 | filwit | yeah |
| 23:11:27 | Araq | maybe I'm not up to date |
| 23:11:29 | filwit | original like looks like: let toMatch = if tfUnresolved in f.flags: a |
| 23:11:40 | filwit | else: a.sons[0] |
| 23:12:07 | Araq | that's my line 821 ... |
| 23:12:25 | filwit | i just pulled so idk |
| 23:12:30 | filwit | maybe you haven't pushed |
| 23:12:46 | Araq | zahary recently got meta-type happy ... |
| 23:13:07 | filwit | anyways, i'm just trying to figure out what to pass to typeRel(..) as the 'toMatch' param |
| 23:13:12 | Araq | so ... I have no idea what tyTypeDesc is these days |
| 23:13:19 | filwit | lol |
| 23:13:28 | filwit | okay, i'll figure it out |
| 23:14:35 | filwit | wait i think i figured out what to do, gotta check |
| 23:15:57 | filwit | thank god Nimrod builds so fast |
| 23:16:33 | * | reactormonk joined #nimrod |
| 23:16:36 | filwit | i imagine hacking on GCC would be an exercise in the virtue of patience |
| 23:16:48 | Varriount | ^ |
| 23:18:48 | renesac | Araq, version 3: https://gist.github.com/ReneSac/a638e1f9d3da866e1f55 |
| 23:18:57 | renesac | now I'm getting something |
| 23:19:09 | * | renesac has a devil smile |
| 23:21:01 | nueva | Araq: can i expect syntax 'import "dir/file.nim"' to not been removed from language in some future? |
| 23:21:21 | renesac | or not.. |
| 23:22:03 | Araq | nueva: I don't dislike it enough to remove it |
| 23:24:47 | renesac | yeah, the optional argument with a non-null value is too evil, and will change the output anyway |
| 23:25:34 | nueva | Araq: it just don't show up in manual (exact syntax with explicit .nim), so I wanted to be sure... |
| 23:26:17 | filwit | woohoo, fixed my first compiler bug! |
| 23:26:34 | * | filwit pats his own back |
| 23:30:36 | Araq | filwit: well done :-) |
| 23:31:14 | Araq | renesac: echo optarg 1, optarg 2, singlearg 2 is hard to read no matter the defintions |
| 23:32:14 | renesac | yeah, I'm learning how to read those monstruosities as I go along, but indeed it is hard to see what is going on |
| 23:32:55 | renesac | I will avoid those confusing expressions, but I can only pray that others do the same ^^" |
| 23:33:45 | Araq | yeah well maybe I should restrict it somehow |
| 23:34:04 | Araq | but then some Haskell-Lover comes along and complains ;-) |
| 23:34:18 | renesac | at least it seems consistent |
| 23:34:46 | Araq | since it's a simple rule in the grammar, I can't see how it can be inconsistent :P |
| 23:34:58 | filwit | gdamnit Kate.. why you add invisible files backup files.. |
| 23:34:59 | EXetoC | filwit: nice. I'll give you a cookie whenever you are in town |
| 23:35:04 | renesac | and some constructions generates errors at compile time |
| 23:35:18 | renesac | Araq, I haven't tried to mix it with "if expressions yet" |
| 23:35:20 | filwit | EXetoC: looking forward to said cookie |
| 23:35:35 | renesac | maybe those not so regular parts of the grammar may pose problems |
| 23:35:45 | Araq | renesac: I applaud your attempts to break stuff :-) |
| 23:36:20 | renesac | sorry for the false positives |
| 23:36:50 | Araq | well now I wonder if you're right and ',' should have lower precedence |
| 23:37:02 | Araq | so foo bar 1, bar 2 is parsed as foo(bar 1, bar 2) |
| 23:37:39 | renesac | that seems easier |
| 23:37:46 | Araq | so () can only be left out for unary applications |
| 23:37:56 | Araq | that would work too |
| 23:38:39 | renesac | I think you can make binary using the "echo 1.func 2 , singlearg 2" |
| 23:38:46 | renesac | *you can still make binary |
| 23:38:52 | Araq | yeah of course |
| 23:39:19 | renesac | that still is rather easy to follow |
| 23:40:05 | Araq | but then (f a, b) doesn't work anymore |
| 23:40:17 | Araq | though that's bad style anyway |
| 23:40:23 | Araq | f(a, b) is better |
| 23:40:48 | vbtt | f(a b, c) becomes f(a(b), c)? |
| 23:40:50 | renesac | lispers will shed a tear, but it is for the greater good |
| 23:40:51 | renesac | XD |
| 23:41:08 | Araq | vbtt: yes |
| 23:41:17 | renesac | and yeah, I would't like to see lispers coding that way in nimrod |
| 23:41:47 | renesac | well, actually that is not confusing... yeah, it would even be ok |
| 23:42:21 | renesac | anyway, I think a lower precedence for , will make nimrod easier to read |
| 23:42:28 | renesac | it seems |
| 23:42:46 | vbtt | that's reasonable. |
| 23:43:11 | Araq | renesac: want to implement it? |
| 23:43:26 | vbtt | my dislike for this reduces *considerably* if it only applies to single argument. |
| 23:43:29 | renesac | Araq, I have no Idea where to start |
| 23:43:35 | vbtt | in fact, it's quite acceptable. |
| 23:43:45 | Araq | renesac: parser.nim, line 675 |
| 23:44:06 | Araq | get rid of the 'while' loop and only call 'parseExpr' once |
| 23:44:50 | Araq | update the grammar comment in line 645, 646 |
| 23:45:12 | Araq | and run 'nimrod c -r compiler/parser.nim' to regenerate the grammar.txt documentation |
| 23:46:08 | Araq | vbtt: I think I agree with you and await/spawn only need the 1 argument version |
| 23:48:33 | * | Varriount|Mobile joined #nimrod |
| 23:49:03 | vbtt | cool. |
| 23:49:22 | filwit | Araq: https://github.com/Araq/Nimrod/pull/849 |
| 23:49:23 | renesac | Araq: I think I'm not up to the task :/ |
| 23:49:39 | vbtt | now, in practice, i'd rarely do await on a single async request |
| 23:50:00 | vbtt | what i really want is await next(r1, r2, r3, r4) |
| 23:50:12 | vbtt | basically a selector - do you have that? |
| 23:50:26 | vbtt | rather, await next([...]) |
| 23:51:07 | vbtt | so i can do.. |
| 23:51:16 | Araq | renesac: np, but I told you everything you need to do ;-) |
| 23:52:14 | Araq | vbtt: do you mean 'AND' or 'OR'? |
| 23:52:29 | renesac | yeah, the problem is that I don't have the understanding concretely apply what you said |
| 23:54:11 | vbtt | Araq:mostly OR, sometimes an AND. when it's OR i want the actual object that's ready. |
| 23:54:51 | vbtt | because this is a common pattern: fire off a bunch of remote rpcs.. wait for them to come back (order doesn't matter) start processing as soon as possible. |
| 23:55:10 | Araq | vbtt: I never thought about 'OR' in non-parallel setting |
| 23:55:22 | Araq | I use condition variables for 'OR' usually |
| 23:55:46 | vbtt | if it's wrapped in a usable stdlib module, that's fine too. |
| 23:55:58 | vbtt | OR is very common. |
| 23:56:24 | vbtt | most async servers use that pattern. |
| 23:56:58 | vbtt | consider the latest distributed data stores - they fire requests to N servers and then wait for N-M to respond. |
| 23:57:50 | Araq | interesting |
| 23:57:59 | Araq | why would they do that? that's wasteful |
| 23:58:20 | vbtt | they want low latency and minimum N redundancy. |
| 23:58:45 | vbtt | so only if data is saved to N-M servers, they are allowed to consider it durable. |
| 23:58:50 | Araq | filwit: wait for zahary's code review please |
| 23:59:11 | vbtt | but eventually they want to replicate to N servers. |
| 23:59:14 | vbtt | something like that. |
| 23:59:25 | Araq | vbtt: I can understand that, but it's wasteful |
| 23:59:26 | vbtt | also I think asyncio features might overlap with the async feature. |
| 23:59:40 | vbtt | Araq:how so? |
| 23:59:57 | vbtt | what other strategy will give you lowest latency and replication to N-M servers? |