| 00:00:19 | BitPuffin | dom96: you are missing out on segfaulting the compiler moments |
| 00:03:57 | Araq | er, what does echo defined(nimnewshared) produce for you guys? |
| 00:05:09 | BitPuffin | nimnewshared? |
| 00:05:13 | BitPuffin | oh |
| 00:05:15 | BitPuffin | I see |
| 00:05:28 | BitPuffin | well doesn't it depend if we compile wiwh -d:nimnewshared ? |
| 00:06:04 | dom96 | Araq: With the latest from git? |
| 00:06:34 | Araq | with the latest working commit |
| 00:06:40 | dom96 | false |
| 00:06:49 | Araq | wtf |
| 00:07:17 | Araq | BitPuffin: nobody likes a smarty |
| 00:07:38 | BitPuffin | Araq: :3 |
| 00:10:21 | Araq | argh |
| 00:10:24 | Araq | I see |
| 00:10:41 | Araq | gah this is nasty |
| 00:16:02 | dom96 | argh |
| 00:16:21 | BitPuffin | aarrrrghh! |
| 00:16:46 | dom96 | It seems I am hitting this bug: https://github.com/Araq/Nimrod/issues/1093 |
| 00:17:52 | dom96 | oh, happy easter btw |
| 00:18:04 | EXetoC | quack |
| 00:18:31 | BitPuffin | wobwobwobwobwob |
| 00:18:39 | BitPuffin | dom96: we should celebrate easter in the vnug! |
| 00:19:18 | * | Equipoise joined #nimrod |
| 00:20:47 | dom96 | BitPuffin: stop it |
| 00:20:58 | BitPuffin | stahp |
| 00:21:16 | BitPuffin | such an easter pooper you you |
| 00:21:58 | Equipoise | "The most important thing in the programming language is the name." Why was the name nimrod chosen? |
| 00:22:26 | BitPuffin | for the sake of inuendo |
| 00:22:34 | BitPuffin | no I dunno, I'd like to know as well |
| 00:23:00 | Araq | Equipoise: because Nimrod built the Tower of Babel |
| 00:23:12 | BitPuffin | so? |
| 00:23:34 | dom96 | and (according to the bible) was the first king ever. |
| 00:24:06 | Equipoise | Araq, he did not. |
| 00:24:13 | BitPuffin | pwned |
| 00:24:31 | EXetoC | xd |
| 00:24:33 | Equipoise | Araq, so you are rebelling against God? |
| 00:24:49 | Araq | Equipoise: no, I am not. |
| 00:25:14 | BitPuffin | he architected it |
| 00:25:27 | EXetoC | rebelling, what |
| 00:25:29 | BitPuffin | Equipoise: he's trying to say that he is the king of god |
| 00:25:44 | Araq | babel refers to the many programming languages out there, creating a mess and that you can create the same mess within a language with a powerful macro system :P |
| 00:26:01 | BitPuffin | ah |
| 00:26:04 | BitPuffin | then it's actually quite a good name |
| 00:27:17 | Araq | well since nobody gets it, I am seriously considering a name change |
| 00:28:10 | Araq | Equipoise: what do you mean "he did not"? |
| 00:28:30 | Equipoise | Araq, Nimrod did not build the tower of babel this is a myth |
| 00:28:43 | BitPuffin | Equipoise: well in the scriptures he did I guess |
| 00:28:51 | BitPuffin | aliens where the ones who actually built it |
| 00:28:51 | Equipoise | Araq, google it |
| 00:29:28 | Equipoise | Araq, though the tower of Babel was not pleasing to God. |
| 00:29:39 | BitPuffin | Araq: I think people would get it if it was actually explained somewhere, I quite like the name now that I know the answer |
| 00:30:08 | Araq | Equipoise: when I google it first hits are wikipedia |
| 00:30:15 | BitPuffin | Equipoise: well, if you wanna argue facts you should probably not bring god in to the conversation |
| 00:30:21 | Araq | so give me the link instead please |
| 00:31:29 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 00:33:15 | Equipoise | www.bibleabookoftruth.com/NimrodAMightyHunter.pdf |
| 00:34:09 | Skrylar | at least he didn't call the compiler dobbs |
| 00:34:54 | Equipoise | Nimrod was the |
| 00:34:55 | Equipoise | king of Babel and surrounding cities in the Land of Shinar but had already moved to Assyria and |
| 00:34:55 | Equipoise | began building Nineveh before the Tower of Babel was started (Genesis 10:10 to 12). |
| 00:37:45 | EXetoC | book of truth |
| 00:39:07 | Araq | "If we put aside all the myths written about Nimrod, scripturally, what do we have left? A powerful, brave man |
| 00:39:09 | Araq | who led his people, fed, protected and built cities for them" |
| 00:39:34 | Araq | still fits the language ;-) |
| 00:42:13 | BitPuffin | :) |
| 00:42:16 | Equipoise | As long as Nimrod is the righteous Nimrod I am here to support it. I'm glad you like the righteous Nimrod. |
| 00:43:23 | Araq | I also picked it because it's ambiguous |
| 00:43:55 | Araq | he was the first king --> positive, he built the tower --> negative |
| 00:44:41 | Araq | now according to you he's only righteous. I have no problems with that. |
| 00:45:40 | Trixar_za | Actually, he built the tower to get closer to God - and for his arrogance God created all the languages in the world to confuse the people building it |
| 00:45:59 | Trixar_za | Which does beg the question of how everybody that DIDN'T build on it got their languages |
| 00:46:47 | Equipoise | However, Ephrem the Syrian (306-373) relates a contradictory view, that Nimrod was righteous and opposed the builders of the Tower. |
| 00:46:51 | Equipoise | that's from wikipedia |
| 00:46:57 | Trixar_za | I found the whole Nimrod thing pretty clever too. First King, Tower, and Language |
| 00:47:05 | Skrylar | you're not supposed to take all of those literally |
| 00:47:39 | Trixar_za | Also he quotes System Shock in the documentation |
| 00:47:44 | Araq | XD |
| 00:47:45 | Trixar_za | That has awesomeness written all over it |
| 00:48:14 | Skrylar | SHODAN for president |
| 00:48:21 | BitPuffin | wait |
| 00:48:23 | BitPuffin | where |
| 00:48:25 | BitPuffin | WHEEERE |
| 00:48:29 | BitPuffin | I'M PLAYING SYSTEM SHOCK RIGHT NOW |
| 00:48:34 | Trixar_za | Seriously? |
| 00:48:40 | Skrylar | BitPuffin: yay synchronicities |
| 00:48:46 | BitPuffin | yeah |
| 00:48:51 | BitPuffin | I'm let's playing on youtube |
| 00:49:24 | Trixar_za | http://nimrod-lang.org/nimrodc.html |
| 00:49:53 | BitPuffin | hahaha |
| 00:49:57 | Skrylar | well i guarantee that nimrod will be famous if you write the first AGI with it :P |
| 00:49:59 | BitPuffin | I think I may have noticed that a long time ago |
| 00:50:13 | BitPuffin | Nimrod is free software; it is licensed under the GNU General Public License. |
| 00:50:15 | BitPuffin | wat |
| 00:50:27 | Skrylar | i thought nimrod was bsd |
| 00:50:29 | BitPuffin | maybe I even pointed it out |
| 00:50:33 | BitPuffin | the shodan thing |
| 00:50:35 | BitPuffin | can't remember |
| 00:50:51 | Araq | BitPuffin: where are you reading that? |
| 00:51:01 | Araq | it's MIT since a quite a while |
| 00:51:07 | BitPuffin | anyways here is the let's play Trixar_za https://www.youtube.com/playlist?list=PLthHtHhsoH6AwkURYrRXTqD0PwXBxJuTW |
| 00:51:16 | BitPuffin | Araq: on the page Trixar_za linked |
| 00:51:34 | flaviu | BitPuffin: Thats a bug |
| 00:51:57 | flaviu | fixed in the latest version |
| 00:52:14 | Trixar_za | Finally made the switch to the MIT License? |
| 00:52:26 | flaviu | Trixar_za: Use the docs at http://build.nimrod-lang.org/docs |
| 00:53:16 | Trixar_za | You mean the page that says 403 forbidden? |
| 00:53:29 | flaviu | Sorry, add a slash |
| 00:53:30 | flaviu | http://build.nimrod-lang.org/docs/ |
| 00:53:56 | NimBot | Araq/Nimrod devel 13b941d Araq [+0 ±1 -0]: attempt to fix bootstrapping |
| 00:54:06 | Trixar_za | Yeah, I figured it out :P |
| 00:54:36 | Trixar_za | It's sad that I knew that about nginx :/ |
| 00:55:52 | Trixar_za | Also as an unrelated note, but I learned more from just idling in this channel and listening in on conversations than I did coding in python and perl. |
| 00:56:41 | Araq | BitPuffin: we also have a quote from bioshock now. |
| 00:56:54 | dom96 | and a Lost reference |
| 00:56:55 | Trixar_za | Pretty much proper object orientation and event based programming |
| 00:57:00 | BitPuffin | Araq: noooooooooooooooooOOOOOOOOOOOOOOOOoooooooooooooo |
| 00:57:03 | BitPuffin | well |
| 00:57:06 | BitPuffin | is it a good quote |
| 00:58:34 | Trixar_za | I think HAL 9000 and GLaDOS quotes are needed - but that's just me :P |
| 01:01:09 | Araq | HAL quotes are in tut1 since forever |
| 01:02:24 | BitPuffin | Araq: is the bioshock quote "The road to hell is paved with good intentions." |
| 01:02:41 | Araq | no |
| 01:03:23 | Araq | "We all make choices. But in the end our choices make us." |
| 01:03:54 | BitPuffin | where is that |
| 01:04:02 | flaviu | https://github.com/Araq/Nimrod/blob/devel/doc/c2nim.txt |
| 01:04:13 | flaviu | Needs atribution |
| 01:04:23 | BitPuffin | so does the one I asked about |
| 01:04:30 | BitPuffin | Araq: too bad bioshock is mediocre |
| 01:04:45 | * | BitPuffin gets down and jumps behind cover |
| 01:05:12 | Araq | it's not. Bioshock Infinite is horrible though. |
| 01:05:48 | * | superfunc quit (Ping timeout: 240 seconds) |
| 01:06:01 | BitPuffin | Araq: it is |
| 01:06:28 | BitPuffin | Araq: what it's got going for it is a pretty nice art style, all be it very plasticy. The story (which is system shock 2 copied and pasted). |
| 01:06:37 | BitPuffin | the gameplay is dumb |
| 01:07:07 | flaviu | Araq: Why is imm a BiggestInt when it must be in the range of a int8? |
| 01:07:23 | flaviu | for genABI |
| 01:08:50 | Araq | flaviu: if n.sons[2].isInt8Lit: |
| 01:08:52 | Araq | c.gABI(n, succ(opc), d, d, n.sons[2].intVal) |
| 01:09:11 | Araq | we know the intVal fits but the compiler doesn't |
| 01:09:41 | Araq | was easier to please the compiler this way I guess |
| 01:09:52 | flaviu | Ok, that makes sense |
| 01:10:27 | Araq | BitPuffin: yeah I have to agree with you on that. |
| 01:11:19 | BitPuffin | but yeah, it's nice exploring the world |
| 01:11:40 | Araq | good night |
| 01:11:45 | BitPuffin | good night! |
| 01:12:00 | Araq | and Varriount, Varriount|Mobile you better be ready for the release tomorrow :-) |
| 01:12:19 | BitPuffin | ohshit it's tomorrow? |
| 01:12:24 | flaviu | Araq: Is there a changelog? |
| 01:12:36 | Araq | flaviu: news.txt |
| 01:13:07 | dom96 | Araq: you broke 16 tests |
| 01:13:22 | BitPuffin | I don't think Araq is ready for the release |
| 01:13:44 | Araq | dom96: I know. will fix it tomorrow |
| 01:14:18 | Araq | glad I only broke 16 tests :P |
| 01:14:35 | dom96 | oh no, typo. I meant 11166 |
| 01:14:39 | dom96 | :P |
| 01:16:16 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 01:16:29 | flaviu | Araq: Have you considered deleting the already-merged branches? |
| 01:16:55 | BitPuffin | there are too many bugs to release in my opinion |
| 01:17:07 | BitPuffin | I mean maybe if we release like a 0.9.4.1 release or something afterwards |
| 01:17:08 | flaviu | There should have been a feature freeze IMO |
| 01:17:12 | BitPuffin | but I don't think that would happen |
| 01:29:25 | dom96 | 'night |
| 01:32:32 | * | EXetoC quit (Quit: WeeChat 0.4.3) |
| 01:40:33 | * | Jesin quit (Ping timeout: 250 seconds) |
| 01:50:37 | Skrylar | i find it really annoying when you read an article, then upon analysis found out the person said nothing |
| 01:55:43 | * | Jesin joined #nimrod |
| 01:57:52 | Varriount|Mobile | Bah, I think I'm turning into a vampire. |
| 01:58:12 | Varriount|Mobile | I'm sleeping during the day and awake at night. |
| 02:00:48 | flaviu | Hmm, I have a statement that eventually returns something, but nimrod doesn't see it as an expr |
| 02:05:15 | * | psquid quit (Ping timeout: 240 seconds) |
| 02:05:55 | * | psquid joined #nimrod |
| 02:08:04 | Equipoise | Araq, I could be wrong about Nimrod being righteous, he could have been corrupted, some say he was some say he wasn't opinions are divided, so more research needs to be done. Yes a name of a language is important, and that's why it is necessary to carefully choose one that is not offensive to anyone. |
| 02:11:39 | fowl | who is it offensive to |
| 02:26:14 | * | q66 quit (Ping timeout: 252 seconds) |
| 02:30:12 | Equipoise | If he actually did become unrighteous then it will have a negative association. For example In Rabbinical Literature: Nimrod is the prototype of a rebellious people, his name being interpreted as "he who made all the people rebellious against God" The unedited full-text of the 1906 Jewish Encyclopedia http://www.jewishencyclopedia.com/articles/11548-nimrod |
| 02:33:57 | Skrylar | everything is offensive to someone |
| 02:34:13 | Skrylar | if all else fails just tell them you named it after bugs bunny and its part of the bundle of stupids |
| 02:34:15 | Skrylar | git+nimrod |
| 02:35:39 | * | Jesin quit (Ping timeout: 240 seconds) |
| 02:38:40 | * | q66 joined #nimrod |
| 02:38:40 | * | q66 quit (Changing host) |
| 02:38:41 | * | q66 joined #nimrod |
| 02:48:35 | BitPuffin | Demos: did you also get disconnected or was it just me |
| 02:48:50 | Demos | just you |
| 03:04:11 | * | Jesin joined #nimrod |
| 03:13:41 | * | ehaliewicz quit (Read error: No route to host) |
| 03:20:09 | * | Equipoise quit (Remote host closed the connection) |
| 03:22:23 | * | q66 quit (Quit: Leaving) |
| 03:25:42 | * | noam quit (Read error: Connection reset by peer) |
| 03:25:58 | * | Demos quit (Quit: Textual IRC Client: www.textualapp.com) |
| 03:26:09 | * | noam joined #nimrod |
| 03:43:47 | * | OrionPK quit (Remote host closed the connection) |
| 03:54:23 | * | Jesin quit (Remote host closed the connection) |
| 04:08:36 | Skrylar | this is a longshot but |
| 04:09:02 | Skrylar | is there some super special way to store a hierarchial document, other than the obvious? |
| 04:09:33 | BitPuffin | Skrylar: what's the obvious? |
| 04:09:36 | Skrylar | i think some of the 'better' tree views just store hollow trees and retrieve the children on first expansion |
| 04:09:44 | Skrylar | BitPuffin: the obvious is loading the whole dataset in to a tree |
| 04:09:50 | BitPuffin | ah |
| 04:09:52 | BitPuffin | yeah |
| 04:09:53 | Skrylar | for things like outline views |
| 04:12:21 | Skrylar | sadly outliners are rare creatures to study |
| 04:12:42 | Skrylar | infoqube is 'neat' but whenever i've used it, it felt like it was dogpiled on a bunch of microsoft ole controls |
| 04:16:01 | * | brson joined #nimrod |
| 04:21:10 | * | ehaliewicz joined #nimrod |
| 04:24:42 | * | xenagi quit (Quit: Leaving) |
| 04:31:14 | * | xenagi joined #nimrod |
| 04:36:31 | * | brson quit (Quit: leaving) |
| 05:00:25 | * | DAddYE joined #nimrod |
| 05:02:50 | * | flaviu quit (Remote host closed the connection) |
| 05:27:16 | * | noam quit (Read error: Connection reset by peer) |
| 06:07:59 | * | xenagi quit (Ping timeout: 252 seconds) |
| 06:11:59 | Skrylar | people are asleep everywhere :< |
| 06:12:04 | Skrylar | i guess there's more yak shaving to be doen |
| 06:15:06 | * | Varriount-Mobile joined #nimrod |
| 06:18:51 | * | Varriount|Mobile quit (Ping timeout: 240 seconds) |
| 06:29:43 | * | bjz_ quit (Read error: Connection reset by peer) |
| 06:30:13 | * | bjz joined #nimrod |
| 06:31:12 | * | BitPuffin quit (Ping timeout: 245 seconds) |
| 06:42:18 | * | Varriount-Mobile quit (Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )) |
| 07:21:18 | * | faassen quit (Remote host closed the connection) |
| 07:40:44 | * | vendethiel quit (Quit: q+) |
| 08:05:40 | * | BitPuffin joined #nimrod |
| 08:10:07 | * | BitPuffin quit (Ping timeout: 250 seconds) |
| 08:14:03 | * | ehaliewicz quit (Ping timeout: 240 seconds) |
| 08:22:45 | * | [1]Endy joined #nimrod |
| 08:56:55 | * | silven joined #nimrod |
| 09:02:37 | * | tangentstorm joined #nimrod |
| 09:02:39 | * | tangentstorm left #nimrod ("WeeChat 0.3.2") |
| 09:28:48 | * | Matthias247 joined #nimrod |
| 09:53:20 | * | io2 joined #nimrod |
| 10:02:42 | * | DAddYE quit (Remote host closed the connection) |
| 10:10:42 | NimBot | Araq/Nimrod devel c80d563 Araq [+0 ±9 -0]: actors compile again |
| 10:39:37 | * | zahary1 quit (Read error: Connection reset by peer) |
| 10:39:37 | * | zahary joined #nimrod |
| 10:44:27 | * | bjz quit (Ping timeout: 240 seconds) |
| 11:00:58 | * | DAddYE joined #nimrod |
| 11:02:28 | * | io2 quit () |
| 11:05:11 | * | DAddYE quit (Ping timeout: 250 seconds) |
| 11:36:29 | Araq | ping zahary |
| 11:57:45 | dom96 | hello |
| 11:58:13 | dom96 | Araq: We're going to include babel with this release right? |
| 11:58:17 | Araq | right |
| 11:58:22 | dom96 | I think it would be a good idea for me to release a new babel version then |
| 11:58:32 | Araq | we should rebuilt C sources |
| 11:58:49 | Araq | so that I can patch more stuff to be thread safe according to the new thread safety model |
| 11:58:52 | dom96 | just download them from nimbuild :D |
| 12:01:49 | * | DAddYE joined #nimrod |
| 12:03:03 | NimBot | Araq/Nimrod devel 39e4e3f Araq [+0 ±1 -0]: fixes OR for int8|int16 etc |
| 12:03:03 | NimBot | Araq/Nimrod devel be6474a Araq [+0 ±15 -2]: removed flawed thread analysis pass |
| 12:05:25 | * | EXetoC joined #nimrod |
| 12:05:54 | Araq | EXetoC: wanna test the new spawn&sync ? |
| 12:06:13 | * | DAddYE quit (Ping timeout: 252 seconds) |
| 12:13:41 | * | q66 joined #nimrod |
| 12:13:41 | * | q66 quit (Changing host) |
| 12:13:41 | * | q66 joined #nimrod |
| 12:13:44 | * | bjz joined #nimrod |
| 12:18:25 | EXetoC | Araq: yeah I'm trying it out now |
| 12:20:02 | Araq | great. add tests please |
| 12:23:57 | Araq | for x in lines(filename): |
| 12:23:58 | Araq | spawn doWork(x) |
| 12:24:00 | Araq | sync() |
| 12:24:05 | Araq | is the minimal canonical example |
| 12:29:42 | NimBot | Araq/Nimrod devel cf3b54f Dominik Picheta [+0 ±1 -0]: Removes tthreadanalysis3 from threadTests spec. |
| 12:34:33 | EXetoC | what should work now? spawn sometimes blocks without executing the statement |
| 12:34:43 | EXetoC | and sync doesn't seem to be needed |
| 12:35:45 | Araq | works in the tests that I came up with ... |
| 12:36:05 | Araq | which OS are you on? |
| 12:37:35 | EXetoC | I added a statement after my spawn loop and it is never executed before all tasks had completed |
| 12:38:04 | EXetoC | does 'for' do anything in that regard in conjunction with spawn? |
| 12:38:11 | EXetoC | Araq: linux x64 |
| 12:38:45 | Araq | 'for' has no special magic |
| 12:38:51 | Araq | it's all in 'spawn' |
| 12:40:01 | Araq | well 'spawn' does block but not for long so your output should be timing dependent |
| 12:40:31 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 12:41:13 | * | Varriount|Mobile joined #nimrod |
| 12:43:01 | EXetoC | Araq: well actually I just incremented a global. I'm trying again with a proc that takes a lot longer to execute |
| 12:43:44 | * | Varriount|Mobile gets on to his laptop to join in the fun. |
| 12:45:40 | * | [2]Endy joined #nimrod |
| 12:47:01 | EXetoC | I still didn't expect it to be so consistent, but sync is indeed necessary for more complicated procs |
| 12:48:12 | EXetoC | but like I said, I frequently have to kill the program |
| 12:48:27 | * | dom96 loves the thrill of release day |
| 12:48:51 | * | [1]Endy quit (Ping timeout: 240 seconds) |
| 12:52:49 | Varriount | Good morning! |
| 12:53:01 | * | Varriount|Mobile quit (Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )) |
| 12:56:23 | Araq | hi Varriount |
| 12:59:10 | dom96 | hello Varriount |
| 12:59:12 | Araq | happy easter everyone |
| 12:59:16 | Araq | bbl |
| 13:02:37 | * | DAddYE joined #nimrod |
| 13:05:47 | EXetoC | the tester doesn't keep going now when a test fails. it never gets to my test |
| 13:07:05 | * | DAddYE quit (Ping timeout: 252 seconds) |
| 13:07:08 | Varriount | dom96: I picture release day as a day when everyone is running around, acting as if the world is ending. |
| 13:07:22 | dom96 | Varriount: Yep. That's why it's so fun. |
| 13:11:02 | * | Jesin joined #nimrod |
| 13:12:34 | Varriount | Hi Jesin |
| 13:12:43 | Jesin | hi |
| 13:12:50 | Varriount | You don't happen to live in Virginia, do you? |
| 13:12:51 | EXetoC | Araq: do you actually want a practical test that processes a file or something? I could add that |
| 13:13:59 | Varriount | dom96: I've got to leave in about an hour and a half for Easter services. (Yes, a religious programmer, I know I'm odd.) |
| 13:14:27 | dom96 | Varriount: Araq won't be back for a few hours anyway I don't think. |
| 13:14:44 | dom96 | Varriount: When will you get back? |
| 13:15:12 | Varriount | dom96: After about an hour and a half. |
| 13:15:27 | dom96 | hrm, that should be fine. |
| 13:15:38 | dom96 | We probably won't release until like 11pm GMT |
| 13:17:35 | * | pdewacht joined #nimrod |
| 13:18:05 | dom96 | hello pdewacht |
| 13:19:14 | Varriount | dom96: I'm currently getting the installation generators prepared. |
| 13:21:31 | dom96 | EXetoC: the tester keeps going for me |
| 13:22:52 | EXetoC | dom96: and with "c system"? |
| 13:24:25 | dom96 | tostring is the only test in system |
| 13:24:33 | dom96 | Only files starting with 't' are tested |
| 13:25:44 | EXetoC | right |
| 13:29:48 | EXetoC | so it this supposed to work before we release? |
| 13:30:47 | dom96 | toString? |
| 13:30:48 | dom96 | yes |
| 13:30:55 | dom96 | reactormonk broke it |
| 13:31:15 | EXetoC | no, tasks |
| 13:31:37 | NimBot | Araq/Nimrod devel 232d252 Dominik Picheta [+2 ±2 -0]: Added new future module with a closure macro. |
| 13:31:41 | * | ehaliewicz joined #nimrod |
| 13:31:49 | dom96 | EXetoC: I think so |
| 13:34:09 | EXetoC | I don't know if it synced correctly there |
| 13:35:55 | NimBot | Araq/Nimrod devel ed935df Dominik Picheta [+0 ±2 -0]: Remove echo from => macro and fix tclosuremacro test. |
| 13:36:03 | * | ehaliewicz quit (Ping timeout: 240 seconds) |
| 13:36:11 | * | io2 joined #nimrod |
| 13:36:33 | dom96 | Once https://github.com/Araq/Nimrod/issues/1093 is fixed, the closure macro will be usable. |
| 13:37:07 | EXetoC | great |
| 13:37:13 | * | darkf quit (Quit: Leaving) |
| 13:37:39 | EXetoC | the test rarely exits when executed through the tester |
| 13:38:27 | EXetoC | timing issue maybe |
| 13:39:36 | Varriount | Is bootstrapping on master broken? |
| 13:39:47 | EXetoC | or maybe it's because I'm doing something else that's resource-intensive |
| 13:41:07 | Varriount | dom96: Where is the implementation for that closure macro going to be placed? |
| 13:41:42 | EXetoC | in system would be really convenient |
| 13:42:45 | Varriount | EXetoC: I ask, because Araq asked me to make a new module ("stdmacros.nim") for this asFunc macro I wrote for him, and I was thinking that dom96's macro should go there as well. |
| 13:44:13 | EXetoC | will it be part of system? |
| 13:44:36 | Varriount | EXetoC: You mean, part of the list of implicitly imported modules? |
| 13:45:24 | EXetoC | they are included really, but yes |
| 13:45:51 | EXetoC | these seem like core features, so having to import explicitly seems silly |
| 13:46:15 | Varriount | That'll be up to Araq |
| 13:46:47 | EXetoC | yeah ok just saying |
| 13:47:18 | Varriount | I could argue that a number of sequtils and strutils procedures are "core features", however that doesn't mean they are included in system. |
| 13:48:50 | EXetoC | hm I don't know |
| 13:50:03 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 13:50:26 | dom96 | Varriount: it's in the future module |
| 13:50:37 | Varriount | O_o |
| 14:01:47 | Varriount | Whoever removed the threadAnalysis option failed to take into account the fact that config files have that option set. |
| 14:03:16 | * | DAddYE joined #nimrod |
| 14:07:18 | EXetoC | Varriount: seq, string add etc are low-level building blocks, whereas most stuff in sequtils/strutils are much less so imo |
| 14:07:27 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 14:11:59 | EXetoC | dom96: so no explicit typing will be necessary when using the closure macro together with map for example? |
| 14:15:23 | dom96 | EXetoC: it may still be necessary, type inference still isn't perfect. |
| 14:16:22 | Varriount | EXetoC: Think of it this way, at least you won't get hundreds of lines of C++ template errors. |
| 14:16:23 | EXetoC | well as long it's a goal |
| 14:18:33 | EXetoC | Varriount: is that related? |
| 14:19:27 | Varriount | EXetoC: I don't know. I've hardly used C++, however I've heard that drowning in template errors is a significant hazard. |
| 14:21:40 | EXetoC | nope, won't happen. that'd be quite the failure :> |
| 14:22:26 | * | Jesin quit (Quit: Leaving) |
| 14:36:01 | * | BitPuffin joined #nimrod |
| 14:45:46 | * | xenagi joined #nimrod |
| 15:02:34 | BitPuffin | Der Hund hat meine Hausarbeit gefressen. |
| 15:04:01 | * | DAddYE joined #nimrod |
| 15:05:37 | BitPuffin | Araq: how is the release going? :a |
| 15:08:17 | * | DAddYE quit (Ping timeout: 250 seconds) |
| 15:32:50 | dom96 | The more I look at Scala the more it resembles Nimrod to me. |
| 15:33:47 | BitPuffin | lol |
| 15:34:04 | BitPuffin | dom96: Scala - nimrod, without showstoppers! |
| 15:34:10 | BitPuffin | dom96: does it have macros though? |
| 15:34:15 | xenagi | Scala allows the metaprogramming of Nimrod? |
| 15:34:23 | dom96 | Scala has macros, yeah. |
| 15:34:28 | BitPuffin | xenagi: I think he means syntactically mostly |
| 15:34:46 | dom96 | Yeah, syntax-wise Scala looks very similar to Nimrod. |
| 15:41:42 | BitPuffin | well to be fair it's not like nimrod has the most unique syntax on earth |
| 15:41:54 | BitPuffin | they were probably inspired by a lot of the same languages |
| 15:43:33 | * | BitPuffin wonders how much work it would be to write a lisp frontend to nimrod |
| 15:44:01 | * | dom96 attempts to write a pattern matching macro |
| 15:46:40 | * | OrionPK joined #nimrod |
| 15:47:51 | Araq | I'm back |
| 15:48:11 | dom96 | I really dislike that even code with no 'do' keyword can become a do notation |
| 15:48:34 | Araq | yeah me too |
| 15:48:43 | Araq | it's a PITA for macros |
| 15:48:49 | BitPuffin | http://youtu.be/lPzN916D8D0 |
| 15:48:58 | dom96 | I will create an issue for this then |
| 15:49:41 | dom96 | Araq: Fix #1093 please |
| 15:49:51 | BitPuffin | fix everything please |
| 15:50:24 | Araq | I think fixing the language so that nimbuild compiles is more important |
| 15:50:31 | EXetoC | dom96: something else turns into 'do' in the AST? |
| 15:51:19 | BitPuffin | Araq: do you think a nimlisp would be possible? |
| 15:51:34 | Araq | BitPuffin: of course |
| 15:51:52 | BitPuffin | I have a feeling it would probably be the easiest nimrod parser to write even |
| 15:51:52 | EXetoC | nope, impossible! |
| 15:52:11 | dom96 | EXetoC: https://github.com/Araq/Nimrod/issues/1120 |
| 15:52:23 | OrionPK | holda |
| 15:52:24 | OrionPK | hola |
| 15:52:30 | Araq | hi pdewacht welcome |
| 15:53:07 | BitPuffin | Araq: are most of the bugs for example with generics and stuff etc backend bugs or bugs with the parser that takes nimrod code and makes the ast |
| 15:53:14 | EXetoC | my guess was correct |
| 15:53:14 | xenagi | Concerning https://github.com/Araq/Nimrod/issues/1081 , where's a good place to start looking? |
| 15:53:54 | BitPuffin | Araq: I guess the only problem is that we don't really have a native list type in nimrod do we |
| 15:55:16 | EXetoC | does it matter? |
| 15:55:31 | BitPuffin | EXetoC: I dunno, it could |
| 15:55:53 | BitPuffin | I don't know how picky it is to write a parser if you are "allowed" to add features that aren't native to nimrod |
| 15:57:32 | * | cark quit (Ping timeout: 246 seconds) |
| 15:57:35 | EXetoC | Araq: how ready do you want spawn to be for the next release? |
| 15:57:51 | Araq | EXetoC: ready. |
| 15:58:24 | EXetoC | dom96 said something about 11pm GMT. that's really soon |
| 15:58:38 | BitPuffin | GMT? |
| 15:58:48 | Araq | BitPuffin: a list type is trivial to implement but cache unfriendly. much better to use something like nimrod's AST |
| 15:58:50 | BitPuffin | why not the timezone that me, EXetoC and Araq live in |
| 15:59:12 | dom96 | who cares, it's like an hours difference anyway |
| 15:59:19 | dom96 | also, it was an estimate |
| 15:59:40 | NimBot | Araq/Nimrod devel 5da463e Jason Livesay [+0 ±1 -0]: Redis: optional pipelining and better tested transactions |
| 15:59:40 | NimBot | Araq/Nimrod devel 9a728b1 Jason Livesay [+0 ±1 -0]: Don't need ref string; use PPipeline instead of ref TPipeline |
| 15:59:40 | NimBot | Araq/Nimrod devel be02aae Jason Livesay [+0 ±1 -0]: factor per comments |
| 15:59:40 | NimBot | Araq/Nimrod devel ebe174c Jason Livesay [+0 ±1 -0]: delete echo statements used for debugging |
| 15:59:40 | NimBot | 4 more commits. |
| 15:59:41 | * | cark joined #nimrod |
| 16:00:10 | BitPuffin | Araq: true, linked lists are not really the bees knees for systems programming. But lists are kind of what makes lisp lisp lol. Like could you do consing on a nimrod ast? |
| 16:00:27 | EXetoC | well like I said, the spawn behavior isn't consistent, but maybe it's possible to fix that today. I'll submit that test |
| 16:00:56 | Araq | EXetoC: when you say it "hangs" what exactly happens? deadlocks? |
| 16:01:14 | BitPuffin | it commits suicide |
| 16:01:23 | EXetoC | Araq: it hangs some time before 'call' is executed |
| 16:01:47 | BitPuffin | Araq: well I shouldn't distract you with lisp talk in a time like this :) |
| 16:01:56 | EXetoC | also, maybe it should be possible to tell the tester to run some tests multiple times |
| 16:04:52 | * | DAddYE joined #nimrod |
| 16:05:45 | EXetoC | it happens a lot more frequently now for some reason |
| 16:06:54 | Araq | hmm 'gcsafe' really should be the default for proc types. damn. |
| 16:09:15 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 16:10:19 | EXetoC | "for i in 0..3: spawn(...) spawn(...)" hangs 19/20 times or something like that, while removing one of the spawns reduces that to about 1/5 |
| 16:11:09 | Araq | so ... now we know |
| 16:11:37 | Araq | nimbuild is provably safe wrt threads not accessing global GC'ed memory |
| 16:12:24 | BitPuffin | EXetoC: \o/ |
| 16:15:07 | EXetoC | might be a linear pattern |
| 16:15:16 | EXetoC | PR sent |
| 16:19:17 | dom96 | Araq: That's good right? |
| 16:20:13 | * | io2 joined #nimrod |
| 16:20:38 | xenagi | any particular reason for having distinct `countdown` and `countup` vs an all-purpose `count` ? |
| 16:22:12 | Araq | dom96: yes. |
| 16:22:43 | Araq | xenagi: all-purpose 'count' decides at runtime if step is negative and so runs in reverse? how is that good design? |
| 16:23:28 | renesac | Araq, it is more flexible, but I guess the performance may be lower |
| 16:23:35 | xenagi | hmm ok, I see. so you remove that first-step conditional by separting them |
| 16:23:42 | renesac | I aways liked the python range, or lua's loops |
| 16:23:59 | renesac | where you can set the step to be whatever you want |
| 16:24:07 | renesac | and you don't need to remember different functions |
| 16:24:27 | xenagi | and conditionals impacts branch prediction which hinders performance |
| 16:25:00 | renesac | well, if it is a constant, and count is inlined as it should, the branch should disapear |
| 16:25:10 | renesac | if it isn't a constant, then you would need to branch anyway |
| 16:25:30 | renesac | so yeah, the performance should be the same |
| 16:27:31 | xenagi | I'm not sure that you would NEED to branch in run-time for count{up|down} |
| 16:27:57 | EXetoC | xenagi: yes if you disregard constant folding |
| 16:28:51 | EXetoC | maybe not |
| 16:29:07 | Araq | xenagi: IMO the 'step' should be a compile-time constant in any case though |
| 16:29:24 | Araq | can't see the value in changing the step at runtime |
| 16:30:07 | xenagi | I see |
| 16:30:12 | renesac | most times you don't right |
| 16:30:20 | renesac | that is why a single function would be better |
| 16:30:24 | renesac | :P |
| 16:31:27 | renesac | and countup allows you to change the step at runtime anyway |
| 16:31:35 | renesac | only disallows negative steps |
| 16:34:16 | Araq | dom96: does website.nim already use sthe new async stuff? |
| 16:34:27 | dom96 | hah no way |
| 16:36:08 | EXetoC | get with the times |
| 16:37:27 | NimBot | nimrod-code/nimbuild master a290127 Araq [+0 ±2 -0]: builder compiles under the new threading model |
| 16:37:27 | NimBot | nimrod-code/nimbuild master e665a7d Araq [+0 ±3 -0]: Merge branch 'master' of https://github.com/nimrod-code/nimbuild |
| 16:49:42 | EXetoC | and passing a proc to a macro generates an ICE. I'll have a look at that |
| 16:50:09 | EXetoC | eh |
| 16:50:13 | EXetoC | I meant to spawn of course |
| 16:50:30 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 17:05:31 | * | DAddYE joined #nimrod |
| 17:05:55 | Varriount | Well, considering all the optimizations that gcc has, I'd find it likely that to iterate up or down would be easily optimized away. |
| 17:07:24 | renesac | that is basic constant folding when the function is inlined |
| 17:09:33 | Varriount | Hm. Has anyone ever tried to add markdown-like syntax parsing to irc messages? |
| 17:10:03 | Varriount | So that things like *Hello* are bold, italicized, etc. |
| 17:10:03 | * | DAddYE quit (Ping timeout: 250 seconds) |
| 17:10:10 | dom96 | IRC already has bold |
| 17:10:21 | Varriount | Oh? |
| 17:10:21 | Araq | Varriount: fiy the GCC version you suggested is fine |
| 17:10:49 | Varriount | Araq: So now all we need to do is tell people to use that, instead of the regular mingw :/ |
| 17:10:52 | dom96 | and color |
| 17:11:10 | Araq | ok guys here is the issue |
| 17:11:22 | Araq | my recent changes break lots of code but it's for the better |
| 17:11:26 | dom96 | and underline, but xchat doesn't insert the correct thing for it for some reason I don't think. |
| 17:11:37 | * | Jesin joined #nimrod |
| 17:11:46 | Araq | and you all tell me to be quick about code breakage before it's too late |
| 17:12:05 | Varriount | Remove the band-aid quickly! |
| 17:12:54 | dom96 | Araq: It just affects thread code right? |
| 17:13:26 | Araq | no. it affects every indirect call too |
| 17:13:41 | Araq | though it's more noticable with threads:on |
| 17:14:02 | Varriount | Wait, so what code is broken, why is it broken, and what should we do? |
| 17:14:12 | dom96 | ^^ |
| 17:14:21 | Araq | annotate things with .gcsafe until the compiler shuts up |
| 17:14:48 | dom96 | why isn't everything gcsafe by default then? |
| 17:15:16 | Araq | that would break everything in the compiler |
| 17:15:31 | Araq | which is using global variables everywhere |
| 17:15:58 | dom96 | Well, I don't get it. |
| 17:16:22 | dom96 | Does code still break even if I don't have threads on? |
| 17:16:40 | Varriount | Are all procedures, from now on, going to have to be annotated with gcsafe? |
| 17:16:58 | Araq | dom96: yes code still breaks, but not significantly |
| 17:17:05 | dom96 | From what I can tell it's just procedures which are used in a proc marked with {.thread.} ? |
| 17:17:19 | Araq | however --threads:on is common: aporia, nimbuild, ... |
| 17:17:32 | dom96 | Araq: Give me an example of where it breaks when threads are *not* on |
| 17:18:59 | Araq | Varriount: no, for most it is inferred but there are a significant amound of procs left where it's not inferable |
| 17:20:10 | dom96 | what happens if I mark a proc {.gcsafe.} when it's actually not gc safe? |
| 17:20:27 | Araq | the compiler tells you |
| 17:21:19 | dom96 | please give me an example of where it breaks when threads are not on |
| 17:22:24 | Araq | the callbacks have to be marked as gcsafe for streams |
| 17:22:42 | Araq | and so you need to annotate the procs you wrap in streams as gcsafe |
| 17:22:47 | Araq | even with --threads:off |
| 17:22:49 | renesac | why not make everything, except what uses global variables, gcsafe? |
| 17:23:02 | renesac | by default? |
| 17:23:10 | Varriount | renesac: Thats what the compiler does, I think. |
| 17:23:22 | Varriount | renesac: But there are cases when it can't infer, I guess. |
| 17:23:36 | renesac | but it can tell that the flat you put is wrong? |
| 17:23:47 | renesac | even if it can't infer? |
| 17:24:26 | Varriount | renesac: flat? |
| 17:24:35 | renesac | *flag |
| 17:29:32 | Araq | brb |
| 17:40:59 | * | Matthias247 joined #nimrod |
| 17:47:31 | Varriount | dom96: So, for this conversion process, how should the work be split? |
| 17:47:53 | dom96 | Varriount: Conversion process? |
| 17:48:27 | Varriount | dom96: Well, whatever process will have to be carried out to get things working with gcsafe |
| 17:48:43 | dom96 | Varriount: Araq is fixing it I think |
| 17:50:51 | Varriount | dom96: But what about all the babel packages? |
| 17:51:09 | Varriount | Especially the ones under nimrod-code? |
| 17:51:32 | dom96 | I don't know. |
| 17:59:43 | NimBot | nimrod-code/nimbuild master 2c6b3ff Araq [+0 ±1 -0]: website compiles again (with a jester patch) |
| 18:04:04 | Araq | dom96: you need to fix jester for gcsafe'ty |
| 18:04:45 | NimBot | Araq/Nimrod devel e6d17e6 Araq [+0 ±21 -0]: made large parts of the stdlib gcsafe |
| 18:04:45 | NimBot | Araq/Nimrod devel 1bb0bde Araq [+2 ±4 -0]: Merge branch 'devel' of https://github.com/Araq/Nimrod into devel |
| 18:05:02 | Araq | Varriount: now it's your turn |
| 18:05:12 | Varriount | My turn for what? |
| 18:05:15 | Araq | you volunteered to update nimrod-code |
| 18:05:25 | Varriount | Oh, wonderful |
| 18:05:51 | Varriount | Well, I'm going to need to get the Win64 build bot back into working order first. |
| 18:06:18 | * | DAddYE joined #nimrod |
| 18:06:44 | Araq | you there is time left, I broke bootstrapping. again. |
| 18:07:25 | Araq | well the thing is |
| 18:07:45 | Araq | we could easily cheerypick fixes into master and release that |
| 18:08:16 | Araq | but now nimbuild depends on a compiler that knows about gcsafe |
| 18:08:25 | Araq | but we could workaround that too |
| 18:10:47 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 18:27:43 | Varriount | Araq: You broke bootstrap on Linux, not on Windows. :D |
| 18:27:56 | Araq | Varriount: that's why I'm on linux now |
| 18:28:08 | Araq | I need to fix 'spawn' anyway |
| 18:28:26 | Varriount | Araq: You should be proud! Usually it's Windows that needs fixing. |
| 18:28:51 | Araq | that only reflects which OSes the major devs are on :P |
| 18:29:08 | Araq | speaking of which |
| 18:29:13 | Araq | who tests macosx? |
| 18:29:38 | Varriount | Unofficially, gradha. |
| 18:34:49 | Araq | also I broke it everywhere unless you compile with a really recent version of the compiler |
| 18:34:53 | Araq | afaict |
| 18:35:59 | renesac | are you sure that it is a good idea do rush a design like this on the release day? |
| 18:36:08 | renesac | not to mention all the breakage... |
| 18:37:07 | Varriount | I was under the assumption that this new stuff wasn't going to be included in what one would assume to be a (relatively) stable release. |
| 18:37:19 | renesac | on babel even |
| 18:37:39 | renesac | then why is araq working on it today? |
| 18:38:17 | Araq | renesac: no, it's a bad idea |
| 18:38:25 | Araq | let's go with the cherry picking |
| 18:39:06 | Araq | we should make 0.9.4 know about but ignore gcsafe |
| 18:39:16 | Varriount | Araq: Or just merge devel into master, and revert the unstable commits. |
| 18:39:44 | Araq | hmm yeah, I should create a new 'concurrency' branch |
| 18:41:22 | renesac | Araq, yep, those are better ideas |
| 18:42:45 | Araq | meh, I can it disable in the current devel version too |
| 18:42:51 | Araq | should be even easier |
| 18:43:44 | Varriount | Araq: Just be careful not to let git bite your hand off. |
| 18:44:37 | renesac | and let useless 'gcsafe' scattered around the stdlib for 0.9.4? |
| 18:45:34 | Araq | renesac: why not? |
| 18:45:48 | Varriount | renesac likes tidiness. |
| 18:45:56 | renesac | people will probably ask what is it |
| 18:46:27 | renesac | but yeah, not really an issue |
| 18:46:48 | renesac | but it will appear on the docs |
| 18:46:59 | Araq | no it will not |
| 18:47:30 | renesac | ok, you will tweak the docgen to forget it also? |
| 18:47:36 | renesac | *ignore |
| 18:52:45 | Araq | renesac: that's a side-effect as the docgen is part of the compiler |
| 18:53:05 | renesac | right |
| 18:55:16 | * | flaviu joined #nimrod |
| 18:59:48 | flaviu | BitPuffin: Scala macros are nearly impossible to use. Much less flexible than nimrod, the docs are worse, and the implementation has Scala's own unique version of boilerplate. |
| 19:01:33 | Araq | argh, how do posix condition variables work again? the extra lock drives me crazy |
| 19:01:40 | Araq | so pointless |
| 19:07:07 | * | DAddYE joined #nimrod |
| 19:11:14 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 19:31:03 | * | Jesin quit (Quit: Leaving) |
| 19:31:17 | * | Araq is stupid for Posix's condition variables |
| 19:31:20 | xenagi | Nimrod isn't compiling anymore (downloaded HEAD from master) |
| 19:31:30 | * | Araq even though he used them before |
| 19:31:31 | xenagi | lib/system/hti.nim(88, 50) Error: invalid pragma: gcsafe |
| 19:31:46 | Araq | xenagi: oh really that's news to us :p |
| 19:31:55 | * | Demos joined #nimrod |
| 19:32:35 | xenagi | lol just thought I'd say something |
| 19:32:58 | Araq | so who fixes sysspawn for posix? |
| 19:33:11 | Araq | works reliably on windows |
| 19:33:23 | Araq | so only the condition variable handling can be wrong |
| 19:34:40 | NimBot | Araq/Nimrod devel da7d6c8 Araq [+0 ±2 -0]: fixes bootstrapping |
| 19:35:52 | BitPuffin | flaviu: okay? haha can't remember claiming anything else |
| 19:36:23 | EXetoC | what are the best ways to debug the compiler? printing the repr of nodes is unreliable.. |
| 19:36:35 | Araq | EXetoC: debug(n) |
| 19:36:47 | EXetoC | oh |
| 19:36:47 | flaviu | I was just telling you of my experience with scala macros |
| 19:36:48 | Araq | EXetoC: echo renderTree(n) # often the better choice |
| 19:38:24 | flaviu | Araq: I wish I had asked you that a while ago, that's really helpful |
| 19:38:29 | EXetoC | xd |
| 19:39:17 | dom96 | also using `??` to check the filename that you are in is useful: if n.info ?? "file.nim": debug n |
| 19:39:32 | * | Demos quit (Ping timeout: 245 seconds) |
| 19:39:34 | flaviu | I wasted a ton of time doing `echo repr n.sons[0].typ.sons[2].kind` |
| 19:40:49 | Araq | flaviu: so fix our internal docs. you read those, RIGHT?! |
| 19:41:34 | Araq | they are slim but never get out of date ... I think |
| 19:41:51 | EXetoC | can the compilation speed be improved even more? |
| 19:42:01 | flaviu | I didn't know they existed, I'm reading them now |
| 19:42:11 | EXetoC | by optimizing the compiler that is. just curious |
| 19:42:53 | Araq | EXetoC: yes and by a large amount |
| 19:43:12 | flaviu | Concurrent compilation? |
| 19:43:20 | Araq | incremental compilation |
| 19:43:46 | Araq | cache what didn't change |
| 19:44:06 | Araq | concurrent compilation will never be possible with nimrod. my prediction. |
| 19:44:40 | flaviu | Can you elaborate on why? |
| 19:45:26 | dom96 | Araq: How can I get the tester to verify a compile-time message for me? (echo treeRepr() in a macro) |
| 19:45:54 | BitPuffin | flaviu: I see |
| 19:45:56 | Araq | dom96: 'msg' vs 'output' iirc |
| 19:46:03 | Araq | 'msg' is about compile-time stuff |
| 19:46:13 | Araq | 'output' about runtime stuff |
| 19:46:17 | EXetoC | Araq: and of individual files? you seem to have performed some optimizations already |
| 19:46:46 | dom96 | Araq: Tried 'msg', doesn't work |
| 19:47:21 | dom96 | but perhaps it's just not printing the failure in the console |
| 19:47:57 | Araq | tmacrogenerics.nim uses 'msg' |
| 19:48:10 | Araq | but maybe that's wrong too |
| 19:48:30 | dom96 | yeah... |
| 19:48:43 | dom96 | That's not good. |
| 19:49:23 | dom96 | and that test does in fact fail |
| 19:49:31 | Araq | hmm 'msg' is still an alias for 'errormsg' |
| 19:49:40 | Araq | I thought zahary said he changed that |
| 19:50:06 | EXetoC | Araq: "internal error: evalOp(mSpawn)" (spawn(someProc)). where do I go from here? |
| 19:50:38 | Araq | teach evalOp it can't evaluate mSpawn at compile time |
| 19:51:08 | EXetoC | ok |
| 19:51:43 | Araq | though in fact ... it can :P |
| 19:51:52 | dom96 | Araq: Should I fix it? |
| 19:52:02 | Araq | dom96: of course |
| 19:53:29 | EXetoC | neat |
| 19:54:31 | Araq | that's the beauty of it, you can simply evaluate X in 'spawn X' at compile time and make 'sync' a no-op |
| 19:54:57 | Araq | but X in general has some effect you don't want at compile time, so it's rather pointless |
| 20:05:05 | EXetoC | should that possibly be supported at another time then? |
| 20:06:35 | EXetoC | just because we can and stuff |
| 20:07:53 | flaviu | Is there a way to get the bounds on a tyRange? I thought I had gotten it to work once, but now I just get a segfault |
| 20:07:54 | * | DAddYE joined #nimrod |
| 20:08:34 | Araq | types.firstOrd and lastOrd do that, flaviu |
| 20:08:37 | Araq | "This type of implementation only works if you can afford to miss an event. I just tested it and ran into many deadlocks. The main reason for this is that the condition variables only wake up a thread that is already waiting. Signals issued before are lost." |
| 20:08:40 | Araq | argh ... |
| 20:08:45 | Araq | no wonder it doesn't work ... |
| 20:09:01 | dom96 | Araq: So this just happened :( https://gist.github.com/dom96/5dfade8c0c4c60afeeb5 |
| 20:10:38 | dom96 | oh, i see. |
| 20:12:57 | * | DAddYE quit (Ping timeout: 276 seconds) |
| 20:15:46 | NimBot | Araq/Nimrod devel 4075159 Araq [+0 ±7 -0]: reintroduce thread analysis but disable it for backwards compatibility |
| 20:18:46 | EXetoC | how do I print the compiler stack trace? |
| 20:21:13 | Araq | EXetoC: writeStackTrace() ? |
| 20:25:33 | dom96 | Araq: Any way to get the compiler to not print the gcc lines but still print 'operation successful'? |
| 20:26:29 | Araq | some obscure verbosity:0 level plut hint[Success]:on perhaps |
| 20:26:35 | Araq | *plus |
| 20:27:04 | dom96 | nope :\ |
| 20:29:01 | Araq | elif optListCmd in gGlobalOptions or gVerbosity > 0: |
| 20:29:03 | Araq | res = execProcesses(cmds, {poEchoCmd, poUseShell, poParentStreams}, |
| 20:29:04 | Araq | gNumberOfProcessors) |
| 20:29:19 | Araq | otherwise it doesn't poEchoCmd |
| 20:29:57 | Araq | ah well, simply check for a substring in the compiler's output instead |
| 20:30:25 | * | OrionPK quit (Remote host closed the connection) |
| 20:30:36 | dom96 | ok |
| 20:30:43 | * | OrionPK joined #nimrod |
| 20:35:59 | flaviu | IMO a stack machine is much easier to reason about |
| 20:37:14 | dom96 | Araq: but then you won't get a nice 'given' in the test results |
| 20:37:27 | dom96 | oh well, should be ok for now I guess |
| 20:38:32 | BitPuffin | haven't seen this before http://lambda-the-ultimate.org/node/4749 |
| 20:38:49 | Araq | flaviu: no, register based machines are much easier |
| 20:38:56 | BitPuffin | ah |
| 20:39:01 | BitPuffin | araq even commented there lol |
| 20:40:06 | Varriount | Araq: Ping me once the release branch is out. Then I can setup the last bits of the installer generators. |
| 20:42:13 | Araq | Varriount: ping |
| 20:42:21 | Araq | what's the release branch? |
| 20:43:16 | NimBot | Araq/Nimrod devel 36fc1d9 Araq [+0 ±1 -0]: spawn has a chance of working on posix |
| 20:43:32 | Araq | EXetoC: see? this is the patch you should have written |
| 20:43:55 | EXetoC | -.- |
| 20:44:09 | Varriount | Araq: Whatever branch the installers need to use |
| 20:44:25 | Araq | simple, hu? I still don't understand why it *only works this way* |
| 20:45:27 | Araq | oh yeah posix_signal doesn't require a lock but when you don't use it, things deadlock |
| 20:45:42 | Araq | yeah right, *not* using a lock makes things deadlock. makes perfect sense |
| 20:46:54 | BitPuffin | Araq: something that might make companies more interested in using nimrod could be saying that "0.9.4 will be supported with bugfix releases once a month (for example) until the release of 0.9.6" |
| 20:51:42 | Araq | BitPuffin: what's the most important bug number for you? |
| 20:52:10 | EXetoC | I was ready to give up, but now it's fixed I think |
| 20:53:15 | * | [2]Endy quit (Ping timeout: 276 seconds) |
| 20:53:18 | NimBot | Araq/Nimrod devel 57cc823 Dominik Picheta [+1 ±2 -0]: Fixes #1093. |
| 20:54:40 | dom96 | Araq: Can we pull #1089 for the release? |
| 20:54:48 | dom96 | https://github.com/Araq/Nimrod/pull/1089 |
| 20:54:58 | flaviu | dom96: Github says that you fixed the bug a minute in the future: 'dom96 closed this issue from a commit in a minute' |
| 20:55:21 | dom96 | flaviu: Yeah, my clock is off. |
| 20:55:57 | dom96 | It runs ahead by like 3 minutes for some reason |
| 20:56:48 | flaviu | Araq: Is there a difference between Registers and Dests? |
| 20:57:15 | * | Demos joined #nimrod |
| 20:58:26 | Araq | dom96: too risky |
| 20:58:59 | dom96 | Araq: ok, but I will need something like that ASAP for Nimbuild's sake. |
| 20:59:02 | Araq | flaviu: not really, Dest can be -1 though indicating that it should be assigned to a temporary |
| 20:59:37 | Araq | tests/manyloc/keineschweine/keineschweine.nim(2, 22) Error: cannot open 'gl' |
| 20:59:48 | Araq | now where is this old gl module ... |
| 21:00:20 | flaviu | Araq: How about pull request #1113? I deleted some old, dead modules in the compiler. |
| 21:00:25 | EXetoC | Araq: uh oh |
| 21:00:38 | EXetoC | let me check that out |
| 21:00:49 | EXetoC | Araq: wanna merge my test? https://github.com/Araq/Nimrod/pull/1121 |
| 21:01:32 | Araq | EXetoC: runs instantly right? |
| 21:01:48 | Araq | cause test suite runtime needs to be considered too |
| 21:02:10 | Araq | EXetoC: just add the gl.nim to keineschweine/lib |
| 21:02:44 | dom96 | if it hangs then it's not a good idea to add it |
| 21:02:51 | dom96 | we still don't have any timeouts in the tester |
| 21:02:53 | dom96 | or nimbuild |
| 21:03:08 | Araq | yeah, good point |
| 21:03:14 | Araq | shouldn't hang anymore though |
| 21:03:24 | Araq | EXetoC: don't bother, I have gl.nim |
| 21:04:20 | EXetoC | you can probably just use opengl.nim though |
| 21:04:41 | Araq | missing the point |
| 21:04:54 | Araq | keineschweine is a stress test and shouldn't have dependencies |
| 21:06:28 | NimBot | Araq/Nimrod devel dad9937 Dominik Picheta [+0 ±2 -0]: Param name and type combos now work in type sig. sugar. |
| 21:06:35 | dom96 | EXetoC: Wanna test my closure macro? |
| 21:08:31 | * | DAddYE joined #nimrod |
| 21:09:54 | * | Demos quit (Ping timeout: 240 seconds) |
| 21:12:42 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 21:13:48 | * | vendethiel joined #nimrod |
| 21:14:47 | dom96 | Araq: doc2 isn't generating docs for my second macro in the future module |
| 21:15:55 | renesac | https://github.com/Araq/Nimrod/pull/1107 <-- something still wrong with my pull request? |
| 21:15:58 | EXetoC | Araq: the test passes successfully now for me too |
| 21:16:16 | EXetoC | tsysspawn.nim |
| 21:16:28 | EXetoC | s/successfully/consistently |
| 21:18:08 | Araq | dom96: only for the 2nd? the 3rd works? |
| 21:19:04 | dom96 | Araq: yeah. I added a third and it works |
| 21:22:36 | Skrylar | well that was a short moment of happiness; actually getting a window on the screen from nimrod |
| 21:22:54 | renesac | Skrylar, \o/ |
| 21:25:05 | Araq | dom96: are sure it's not some "doc2 never generates immediate macro docs" issue? |
| 21:25:14 | dom96 | maybe |
| 21:26:34 | EXetoC | flaviu: trying to add float ranges? |
| 21:26:44 | EXetoC | or rather to make them usable |
| 21:27:08 | flaviu | EXetoC: No, the VM doesn't support arrays like array[1..10, int] |
| 21:27:15 | BitPuffin | Araq: lemme check |
| 21:27:26 | dom96 | Araq: I'm getting an access denied when bootstrapping |
| 21:27:37 | dom96 | When it tries to copy compiler/nimrod.exe to bin/nimrod.exe |
| 21:27:58 | BitPuffin | Araq: probably #1082 but that's a zahary bug |
| 21:28:44 | dom96 | hrm |
| 21:28:49 | dom96 | Never mind |
| 21:28:59 | Araq | flaviu: it's a simple c.gen(opcSubImm, idx, idx, firstOrd(foo.typ)) before the array access :P |
| 21:29:23 | Araq | but surely it's useful when you learn the inner workings of the VM |
| 21:30:19 | flaviu | Araq: What if firstOrd > 128? |
| 21:30:50 | * | dom96 wonders how he got a zombie nimrod process |
| 21:30:54 | BitPuffin | Araq: do you review zahary's code before merging? |
| 21:30:55 | EXetoC | Araq: https://gist.github.com/EXetoC/e4db8952b9cbf660fa2f this is all I had to do to make float ranges be usable. might it be that simple? |
| 21:31:33 | Araq | flaviu: internalError(n.info, "use a meaningful index you hippie") |
| 21:31:59 | Araq | or you load the constant then with ldConst |
| 21:32:01 | EXetoC | I thought I might have to add some type checks or something, but I couldn't come up with any examples that would fail |
| 21:32:13 | dom96 | Anyone wanna test my closure macro!??! |
| 21:32:13 | Araq | EXetoC: float ranges have been implemented |
| 21:32:21 | EXetoC | when? |
| 21:32:36 | flaviu | Araq: Mark https://github.com/Araq/Nimrod/issues/1095 as solved |
| 21:32:49 | flaviu | Thanks, thats awesome |
| 21:33:27 | Araq | dom96: sorry I'm busy |
| 21:33:57 | NimBot | Araq/Nimrod devel 443fdd6 Dominik Picheta [+0 ±1 -0]: Fixed docs in future module. |
| 21:33:57 | NimBot | Araq/Nimrod devel ca2b73f Dominik Picheta [+0 ±1 -0]: Revert 4b09baa0a and 33fcd1123. |
| 21:34:00 | EXetoC | flaviu: which commit fixed it? |
| 21:34:23 | NimBot | Araq/Nimrod devel 171f4a2 EXetoC [+0 ±1 -0]: Fix spawn ICE on invalid argument. |
| 21:34:23 | NimBot | Araq/Nimrod devel d29cf2d EXetoC [+1 ±0 -0]: Add test for bad spawn argument. |
| 21:34:23 | NimBot | Araq/Nimrod devel 38892bb Andreas Rumpf [+1 ±1 -0]: Merge pull request #1124 from EXetoC/spawn-arg-check... 2 more lines |
| 21:34:38 | EXetoC | that issue is the only thing that shows up in my search |
| 21:35:22 | NimBot | Araq/Nimrod devel 29261a0 flaviut [+0 ±1 -0]: Document vmgen.nim a bit |
| 21:35:22 | NimBot | Araq/Nimrod devel e34c3e7 Andreas Rumpf [+0 ±1 -0]: Merge pull request #1123 from flaviut/bug1110... 2 more lines |
| 21:35:39 | flaviu | EXetoC: 7056ceda6727d1725645ab046fee4c0d6bb15501 |
| 21:36:28 | flaviu | NM, not that |
| 21:36:43 | EXetoC | yeah that didn't seem right |
| 21:38:01 | flaviu | I can't find any reference to them in the commit messages |
| 21:38:31 | EXetoC | I can't find it either |
| 21:39:27 | NimBot | Araq/Nimrod devel e2fe9dd ReneSac [+0 ±1 -0]: Additions and clarifications to tutorial 1. |
| 21:39:27 | NimBot | Araq/Nimrod devel 56a6928 ReneSac [+0 ±1 -0]: Referential data types may need to be declared.... 2 more lines |
| 21:39:27 | NimBot | Araq/Nimrod devel 1205f91 Andreas Rumpf [+0 ±1 -0]: Merge pull request #1107 from ReneSac/devel... 2 more lines |
| 21:39:46 | NimBot | Araq/Nimrod devel c163c06 Grzegorz Adam Hankiewicz [+0 ±1 -0]: Avoids idetools crash on nil parameters. |
| 21:39:46 | NimBot | Araq/Nimrod devel 726c709 Andreas Rumpf [+0 ±1 -0]: Merge pull request #1097 from gradha/pr_avoid_idetools_crash... 2 more lines |
| 21:40:31 | NimBot | Araq/Nimrod devel 37ac424 Clay Sweetser [+0 ±2 -0]: Added Windows implementation of getFileInfo procedures |
| 21:40:31 | NimBot | Araq/Nimrod devel 8af083c Clay Sweetser [+0 ±1 -0]: Added Posix implementation of getFileInfo, organized code. |
| 21:40:31 | NimBot | Araq/Nimrod devel 79f0c66 Clay Sweetser [+0 ±2 -0]: Completed Linux/Posix implementation of getFileInfo... 2 more lines |
| 21:40:31 | NimBot | Araq/Nimrod devel 73570cb Clay Sweetser [+0 ±1 -0]: Allowed getFileInfo to accept TFile objects. |
| 21:40:31 | NimBot | 3 more commits. |
| 21:41:27 | BitPuffin | wa |
| 21:41:32 | BitPuffin | so many commits :P |
| 21:41:42 | flaviu | He's pulling requests |
| 21:42:14 | EXetoC | flaviu: do you know when it was fixed? |
| 21:42:24 | flaviu | No idea, ask Araq |
| 21:45:08 | EXetoC | ok |
| 21:50:02 | Araq | dom96: https://github.com/Araq/Nimrod/issues/1085 is fixed now? |
| 21:51:01 | dom96 | nope |
| 21:52:31 | * | DAddYE joined #nimrod |
| 21:54:04 | NimBot | Araq/Nimrod devel 5cf8c05 Dominik Picheta [+0 ±1 -0]: Fixes #1119. |
| 21:57:02 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 21:57:04 | Araq | dom96: was that reactormonk's bug? |
| 21:58:25 | * | OrionPK quit (Remote host closed the connection) |
| 21:58:29 | dom96 | No, I already fixed that |
| 21:58:37 | dom96 | oh forgot that had an issue |
| 21:58:42 | * | OrionPK joined #nimrod |
| 21:58:43 | dom96 | That was gorge |
| 21:58:49 | Araq | :O |
| 22:00:07 | Araq | nice fix |
| 22:00:20 | dom96 | It's correct right? |
| 22:00:24 | Araq | yup |
| 22:00:26 | dom96 | good |
| 22:10:50 | NimBot | Araq/Nimrod devel 472190b Araq [+0 ±2 -0]: fixes #1085 |
| 22:10:50 | NimBot | Araq/Nimrod devel e3fab47 Araq [+0 ±4 -0]: attempt to make some tests green |
| 22:10:50 | NimBot | Araq/Nimrod devel 2c97242 Araq [+3 ±10 -0]: Merge branch 'devel' of https://github.com/Araq/Nimrod into devel |
| 22:16:28 | fowl | i needed md5 functions from openssl/md5, if anybody else need them: https://gist.github.com/fowlmouth/11126623 |
| 22:19:01 | EXetoC | do any type classes include nkVarTy? |
| 22:20:26 | Araq | who knows |
| 22:21:08 | fowl | is there a curl wrapper? |
| 22:22:52 | dom96 | Araq: Still want to move redis out? |
| 22:23:12 | Araq | no |
| 22:23:27 | Araq | I want you to add Babel to windows installer. somehow |
| 22:23:37 | Araq | we can move redis later |
| 22:23:43 | EXetoC | Araq: n.kind is nkVarTy but I can't figure out where in "case n.kind" in semExpr that it's matched |
| 22:23:50 | EXetoC | not in the 'else' branch apparently |
| 22:24:08 | Araq | nkVarTy is done by semTypeNode |
| 22:24:57 | EXetoC | ok there's a range case here. sneaky |
| 22:25:52 | Araq | BitPuffin: so now I need to look for linagl to fix your showstopper bug. how nice |
| 22:26:08 | Araq | no wonder nobody fixes it :P |
| 22:26:15 | EXetoC | it's only a handful of values inbetween, so listing them all would be more clear |
| 22:27:41 | renesac | fowl, I hope you needed it for some backwards compatibility thing, and I remember seeing a md5 wrapper for nimrod, not sure if for openssl |
| 22:28:10 | dom96 | Araq: I thought that was Varriount's job. |
| 22:28:48 | EXetoC | I'm trying to fix this UDTC bug |
| 22:29:19 | Araq | EXetoC: what's UDTC? |
| 22:29:51 | Araq | fowl: there is lib/libcurl.nim |
| 22:30:03 | EXetoC | Araq: user defined type class |
| 22:30:14 | dom96 | fowl: Why not use the httpclient module? |
| 22:31:03 | renesac | hum, ok, it seems implemented in nimrod rather than a wrapper |
| 22:31:16 | renesac | oops, or not |
| 22:31:44 | Araq | babel install linagl |
| 22:31:46 | Araq | Downloading linagl into /tmp/babel/linagl using hg... |
| 22:31:47 | Araq | sh: 1: hg: not found |
| 22:32:22 | renesac | oh, it is indeed in nimrod |
| 22:32:36 | renesac | why cstring then? |
| 22:33:12 | renesac | oh, to simulate a slice? |
| 22:34:11 | Araq | sometimes we do that, yeah |
| 22:35:07 | EXetoC | well, do you have mercurial? |
| 22:35:44 | flaviu | Araq: Its an easy fix on arch: `sudo pacman -S mercurial` :P |
| 22:36:50 | Araq | flaviu: it's easy here too |
| 22:37:47 | dom96 | I should add a fallback to babel in case hg or git is not installed |
| 22:38:13 | Araq | dom96: it's fine for now. the error was easy enough to understand |
| 22:39:05 | dom96 | It's not on Windows heh |
| 22:40:57 | EXetoC | "var checkedBody = c.semTryExpr(c, body.n[3].copyTree, bufferErrors = false)" this returns 'not nil' when I try to match against 'var' parameters for UDTCs |
| 22:42:23 | EXetoC | "if checkedBody == nil: return isNone". this is in sigmatch.matchUserTypeClass. I'm not sure what to do now |
| 22:42:26 | EXetoC | zahary: ? |
| 22:43:50 | Araq | he's in his never ending vacation |
| 22:44:39 | EXetoC | ok maybe you have a clue |
| 22:45:41 | Araq | not really |
| 22:47:27 | fowl | dom96, i was having trouble with downloading from dropbox |
| 22:47:55 | dom96 | fowl: Where is your issue report? |
| 22:48:08 | fowl | over there |
| 22:48:23 | * | dom96 takes out binoculars |
| 22:48:28 | dom96 | can't see it |
| 22:49:32 | EXetoC | Araq: does this help? https://gist.github.com/EXetoC/7eba2d96c2c0c363acc2 |
| 22:50:49 | EXetoC | don't bother if nothing comes to mind right away. I just noticed this "dummyType = if a.kind != tyVar: makeVarType(c, a) else: a" which could be of relevance |
| 22:51:54 | Araq | EXetoC: are you sure it's not simply another x.f(a) vs f(x, a) issue? |
| 22:51:59 | Araq | try |
| 22:52:09 | Araq | put(c, var T) in the generic declaration |
| 22:53:09 | EXetoC | no change |
| 22:53:25 | * | DAddYE joined #nimrod |
| 22:57:33 | * | superfunc joined #nimrod |
| 22:58:03 | * | DAddYE quit (Ping timeout: 276 seconds) |
| 23:00:32 | * | Demos joined #nimrod |
| 23:00:35 | * | ehaliewicz joined #nimrod |
| 23:06:18 | * | BitPuffi1 joined #nimrod |
| 23:08:09 | EXetoC | no wait, "var T"? :E |
| 23:08:18 | * | BitPuffin quit (Ping timeout: 240 seconds) |
| 23:09:23 | EXetoC | that's wrong. it doesn't matter though |
| 23:14:17 | * | xenagi quit (Quit: Leaving) |
| 23:14:33 | NimBot | Araq/Nimrod devel e809302 Dominik Picheta [+0 ±1 -0]: Tester now ignores deprecation warnings. |
| 23:14:40 | fowl | EXetoC, i fixed it |
| 23:14:49 | fowl | var cvar = c |
| 23:14:49 | fowl | put(cvar, int) |
| 23:15:00 | fowl | works with T also |
| 23:15:41 | fowl | EXetoC, "var tvar: T" it works with put(cvar,tvar) |
| 23:16:04 | fowl | oh and i changed put to take var |
| 23:16:32 | fowl | bullet point: use var to make inner copy if you need var type |
| 23:18:19 | * | Demos quit (Ping timeout: 252 seconds) |
| 23:19:17 | fowl | dom96, can i add those md5 funcs to openssl? |
| 23:19:42 | EXetoC | ok |
| 23:20:57 | EXetoC | I might try to fix that still, but this might allow me to perform some practical experiments |
| 23:21:22 | dom96 | fowl: Araq's call |
| 23:21:37 | Araq | shouldn't we get rid of openssl asap? |
| 23:21:48 | Araq | and wrap the mozilla stuff instead? |
| 23:22:30 | dom96 | Yeah, because getting openssl to work was so simple. |
| 23:23:00 | Araq | I bet the mozilla stuff is |
| 23:23:02 | fowl | what would be the easiest way to make nake compile nakefiles with -d:ssl |
| 23:23:09 | * | Demos joined #nimrod |
| 23:23:20 | dom96 | heartbleed was patched |
| 23:23:37 | dom96 | openssl is still the most popular |
| 23:23:48 | dom96 | but i'll look into it |
| 23:24:01 | fowl | dom96, i dont want to ask him, ill just do the pr >_> |
| 23:24:18 | Araq | too late |
| 23:25:25 | BitPuffi1 | how is the release going? |
| 23:27:40 | Araq | it will be a pretty crappy release ... |
| 23:28:46 | dom96 | oh come on |
| 23:29:01 | dom96 | be positive |
| 23:29:24 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 23:29:27 | Araq | does the matrix stuff work? no. the new VM? sometimes. async? testing right now on linux |
| 23:29:48 | flaviu | Araq: There's more new stuff than Java has had added in the past few releases :P |
| 23:30:09 | Araq | the new thread stuff? breaks code, but I suppose spawn is really cool |
| 23:30:42 | flaviu | Have you considered weekly releases until 1.0? |
| 23:30:59 | dom96 | we have cool closures now though |
| 23:31:12 | * | Demos quit (Ping timeout: 276 seconds) |
| 23:31:13 | flaviu | dom96: Your macro is in the stdlib now? |
| 23:31:18 | dom96 | flaviu: yes! |
| 23:31:21 | dom96 | Please test it! |
| 23:31:29 | dom96 | it's in the future module |
| 23:31:34 | Araq | I'm considering telling people to built from master for a stable version and from devel to get a cutting edge version |
| 23:32:20 | dom96 | Araq: Isn't that what we already tell people? |
| 23:32:38 | flaviu | dom96: We tell people to use devel for everything |
| 23:33:09 | dom96 | Well. That's because master is extremely outdated. |
| 23:33:16 | Araq | not anymore |
| 23:33:23 | Araq | we merged it before the purge |
| 23:33:43 | Araq | that's why I developed the thread stuff directly on devel btw |
| 23:33:57 | dom96 | Er, isn't the plan to merge devel into master once a release happens? |
| 23:34:12 | Araq | well I was positive :P |
| 23:36:20 | flaviu | dom96: Can you use assert in the docs? If I ever turn them into tests, that would be helpful. |
| 23:37:19 | * | darkf joined #nimrod |
| 23:37:28 | renesac | the tester should try to execute the code snippets on the docs |
| 23:37:50 | renesac | you have syntax identifying them, so that should be possible |
| 23:38:14 | flaviu | renesac: Yes, definitely possible. I have some half-completed code that extracts them |
| 23:38:17 | dom96 | flaviu: Assert in code examples will add a lot of noise. |
| 23:38:36 | renesac | well, sometimes the examples use non-existing variables, and that will be broken |
| 23:38:45 | renesac | yeah, not so simple |
| 23:39:13 | Araq | dom96: doc2 crashes with an assertion for future.nim |
| 23:39:27 | Araq | I'm working on it but gradha's code is awful |
| 23:39:28 | flaviu | renesac: Are those good examples then? A good example should be self-contained |
| 23:39:51 | renesac | flaviu, and it should be concise |
| 23:39:54 | dom96 | Araq: huh, must be linux specific? |
| 23:40:19 | Araq | well it's an assert |
| 23:40:28 | Araq | if you use release mode it might fail silently |
| 23:40:44 | dom96 | ahh |
| 23:40:47 | dom96 | that's it |
| 23:41:28 | BitPuffi1 | Araq: so postpone it |
| 23:41:42 | BitPuffi1 | no more features |
| 23:41:50 | BitPuffi1 | get master in a fairly stable state |
| 23:41:57 | BitPuffi1 | then start working on devel |
| 23:42:09 | BitPuffi1 | release builds every 2 weeks or so based on master |
| 23:43:02 | BitPuffi1 | releasing something that isn't ready for the sake of releasing doesn't result in anything but a bad image |
| 23:43:03 | dom96 | we've postponed long enough |
| 23:43:12 | dom96 | There will always be bugs |
| 23:43:22 | renesac | release a beta |
| 23:43:22 | BitPuffi1 | like "well I tried nimrod but I couldn't do anything because the compiler was buggy" |
| 23:43:26 | renesac | :P |
| 23:43:29 | BitPuffi1 | yeah I agree |
| 23:43:32 | BitPuffi1 | a beta would be ok |
| 23:43:45 | flaviu | +1 "well I tried nimrod but I couldn't do anything because the compiler was buggy" |
| 23:44:12 | Araq | makes no sense to call this version a "beta". a "beta" for what? |
| 23:44:22 | BitPuffi1 | for 0.9.4 |
| 23:44:26 | EXetoC | Araq: ok so "var cvar c; put(cvar, T)" works, but I think "put(var c, T)" should work as well. how can I treat these in the same way? |
| 23:44:34 | renesac | of 0.9.4? |
| 23:44:36 | renesac | :P |
| 23:44:42 | BitPuffi1 | it's not like anyone will give a shit if we postpone it |
| 23:44:51 | BitPuffi1 | what they will give a shit about is releasing something buggy |
| 23:45:15 | renesac | BitPuffi1, postponing it while the main website points people to version 0.9.2 is bad |
| 23:45:28 | dom96 | BitPuffi1: The current version doesn't work on Ubuntu |
| 23:45:30 | BitPuffi1 | renesac: so update the website |
| 23:45:37 | BitPuffi1 | say |
| 23:45:39 | dom96 | And it has many other issues. |
| 23:45:40 | BitPuffi1 | if you want to try nimrod |
| 23:45:47 | BitPuffi1 | you should build from source |
| 23:45:55 | BitPuffi1 | just follow the instructions here: |
| 23:46:07 | BitPuffi1 | hell we could even write a script that does the building and installation for you |
| 23:46:47 | BitPuffi1 | in fact don't even link to 0.9.2 |
| 23:46:51 | BitPuffi1 | it's dead |
| 23:47:02 | BitPuffi1 | link to the master builds of the documentation |
| 23:47:04 | BitPuffi1 | I mean come on |
| 23:48:34 | BitPuffi1 | well at least that's what I think |
| 23:49:36 | BitPuffi1 | like the only ones that will be disappointed if we don't release today would be those of us in here who was hoping for a release today, and we already understand the situation so it's not like anyone of us will go "fuck it!" and leave because of it |
| 23:50:18 | Araq | oh really? and how do we make reddit announcements without a release and attract fresh blood? |
| 23:50:37 | flaviu | BitPuffi1: I agree, just point to the github repo. Rust is exactly the same, they have a link to a nightly release. |
| 23:50:47 | BitPuffi1 | Araq: we write blogposts about every new feature that gets added in the master branch |
| 23:50:58 | BitPuffi1 | and make it easy to get the master branch, ie script the installation process |
| 23:51:07 | BitPuffi1 | first we need to fix koch install though |
| 23:51:25 | BitPuffi1 | now why the fuck am I BitPuffi1 |
| 23:51:28 | * | BitPuffi1 is now known as BitPuffin |
| 23:54:07 | * | DAddYE joined #nimrod |
| 23:58:33 | * | Demos joined #nimrod |
| 23:59:09 | * | DAddYE quit (Ping timeout: 276 seconds) |