| 00:09:30 | * | johnsoft quit (Ping timeout: 250 seconds) |
| 00:09:43 | * | johnsoft joined #nimrod |
| 00:23:07 | * | brson quit (Ping timeout: 245 seconds) |
| 00:26:07 | superfunc | sup everyone |
| 00:26:45 | adoniscik | yo, superfunc |
| 00:27:11 | * | Demos quit (Read error: Connection reset by peer) |
| 00:27:12 | adoniscik | is there a way to create a shorthand for long types that use generics? |
| 00:28:50 | adoniscik | I tried type T[I] = array[I, float] |
| 00:29:30 | adoniscik | either that or something else is causing a internal error: invalid kind for last(tyAnything) |
| 00:30:23 | adoniscik | okay, fixed it. never mind :) |
| 00:30:35 | superfunc | should work |
| 00:30:52 | superfunc | type mytype[T,K] = TTable[T,K] for example |
| 00:31:19 | adoniscik | I just needed to include the [] in the proc signature too |
| 00:31:30 | superfunc | ah, right on. Glad you fixed it. |
| 00:31:31 | adoniscik | after the T |
| 00:31:43 | adoniscik | thanks, superfunc |
| 00:44:59 | * | bjz joined #nimrod |
| 01:01:14 | * | flaviu quit (Ping timeout: 240 seconds) |
| 01:10:29 | * | darkfusion quit (Ping timeout: 272 seconds) |
| 01:15:50 | adoniscik | When I set the return type of the second argument in nm to auto I get a different answer. Can anyone tell me why? http://pastebin.com/zk3DqRyD |
| 01:17:20 | adoniscik | to be precise, I mean the second argument in the example at the end |
| 01:23:55 | * | q66 quit (Quit: Leaving) |
| 01:25:48 | * | flaviu joined #nimrod |
| 01:26:44 | superfunc | lemme look |
| 01:34:08 | superfunc | adoniscik: where did you declare MAX_ITER |
| 01:36:35 | superfunc | what are the two different types the compiler infers? |
| 01:38:07 | adoniscik | I don't know, I just see the result. How can I find out? Let const MAX_ITER = 1000 |
| 01:39:44 | * | bjz quit (Ping timeout: 260 seconds) |
| 01:40:20 | * | bjz joined #nimrod |
| 01:44:55 | adoniscik | how can I something's type? I tried type() |
| 01:46:21 | adoniscik | the type's seem equivalent yet the results are different. weird! |
| 01:58:36 | * | Fx00F joined #nimrod |
| 01:59:56 | * | vbtt quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 02:04:05 | adoniscik | how can you obtain a variable's type? I get something similar to this: https://github.com/Araq/Nimrod/issues/1146 |
| 02:10:31 | * | bjz_ joined #nimrod |
| 02:12:05 | superfunc | Araq: I can't seem to recall, what is the way to print type info? |
| 02:12:18 | * | bjz quit (Ping timeout: 255 seconds) |
| 02:17:11 | superfunc | adoniscik: As a stopgap measure, you can do echo(type(...)) which will give you a compiler error showing you the type info you want |
| 02:17:20 | * | error424 joined #nimrod |
| 02:17:25 | superfunc | e.g. let x = 4 echo(type(x)) |
| 02:17:52 | superfunc | will print out Error: type mismatch: got (typedesc[int]) |
| 02:18:15 | superfunc | the part in typedesc[..] will tell you the inferred type |
| 02:19:46 | adoniscik | actually I just get internal error: GetUniqueType. Is there another way? My variable is actually a proc, as you might know. |
| 02:22:01 | * | goobles quit (Ping timeout: 246 seconds) |
| 02:22:59 | superfunc | set a var equal to calling the proc |
| 02:23:05 | superfunc | then check the type of that var |
| 02:26:21 | adoniscik | okay, good. I get FNum[range 0..1(int)] with and without auto. |
| 02:26:54 | adoniscik | but the result with auto is wrong. this feels like a bug to me |
| 02:28:10 | superfunc | Yeah, report it in github please |
| 02:28:38 | superfunc | Be sure to include a code snippet and the version of the compiler you are using |
| 02:33:00 | * | Jesin quit (Ping timeout: 255 seconds) |
| 02:34:16 | * | y2f0 quit (Ping timeout: 246 seconds) |
| 02:39:17 | * | ics joined #nimrod |
| 02:45:26 | * | Jesin joined #nimrod |
| 02:49:47 | * | ics quit (Ping timeout: 245 seconds) |
| 02:56:10 | * | xtagon quit (Quit: Leaving) |
| 03:17:06 | * | fowl quit (Quit: goodbye, cruel server) |
| 03:19:33 | * | darkfusion joined #nimrod |
| 03:23:59 | * | springbok quit (Ping timeout: 264 seconds) |
| 03:27:14 | * | flaviu quit (Ping timeout: 240 seconds) |
| 03:31:53 | * | error424 quit (Remote host closed the connection) |
| 03:33:59 | * | saml_ quit (Quit: Leaving) |
| 03:34:32 | * | darkfusion quit (Ping timeout: 260 seconds) |
| 03:45:14 | * | kemet joined #nimrod |
| 03:47:03 | * | kemet quit (Client Quit) |
| 03:51:15 | * | mwbrown quit (Ping timeout: 250 seconds) |
| 03:53:45 | * | bjz_ quit (Read error: Connection reset by peer) |
| 03:54:01 | * | bjz joined #nimrod |
| 04:08:20 | * | superfunc quit (Quit: leaving) |
| 04:10:18 | adoniscik | can you use the auto return type with arrays? |
| 04:23:36 | Fx00F | yes |
| 04:24:37 | Fx00F | hmm, with newSeq arrays at least |
| 04:33:37 | * | fowl joined #nimrod |
| 04:42:36 | * | ics joined #nimrod |
| 05:02:50 | * | kshlm joined #nimrod |
| 05:07:42 | adoniscik | is it safe to infer return types (using auto) from array literals ? |
| 05:15:15 | adoniscik | eureka! I solved it: [1,2,3] is not the same as array([1,2,3]) |
| 05:15:56 | adoniscik | when I use return the former, I expect auto to infer an array but it's not; it's an array *constructor*. |
| 05:19:56 | adoniscik | Is this expected behavior? I'd expected them to be interchangable |
| 05:37:42 | * | kshlm quit (Ping timeout: 245 seconds) |
| 05:37:59 | * | kshlm joined #nimrod |
| 05:44:14 | * | BitPuffin quit (Ping timeout: 240 seconds) |
| 05:57:32 | * | darkfusion joined #nimrod |
| 06:02:43 | * | goobles joined #nimrod |
| 06:03:51 | * | darkfusion quit (Ping timeout: 250 seconds) |
| 06:04:00 | * | darkfusion joined #nimrod |
| 07:11:03 | * | Hat_and_Cloak joined #nimrod |
| 07:16:14 | * | Fx00F quit (Quit: Lost terminal) |
| 07:18:15 | * | Hat_and_Cloak left #nimrod ("Leaving") |
| 07:21:35 | * | ics quit (Ping timeout: 264 seconds) |
| 07:24:23 | * | kunev joined #nimrod |
| 07:26:11 | * | adoniscik quit (Ping timeout: 250 seconds) |
| 07:51:46 | * | Ven joined #nimrod |
| 07:51:46 | * | Ven quit (Client Quit) |
| 07:58:03 | * | Ven_ joined #nimrod |
| 08:02:33 | * | Ven_ quit (Ping timeout: 240 seconds) |
| 08:16:42 | Skrylar | o_O |
| 08:16:49 | Skrylar | Computer algebra systems are really weird. |
| 08:21:21 | * | zahary joined #nimrod |
| 08:25:24 | * | Trustable joined #nimrod |
| 08:51:37 | Skrylar | i just realized something ironic |
| 08:51:55 | Skrylar | if you ask about calculators in math class, a lot of people will vehemently defend the "no you should mentate all of it" |
| 08:52:09 | Skrylar | yet most of these same people, if they are programmers, are likely unable to use the CLI |
| 08:52:36 | Skrylar | which means they don't actually believe in learning to do things the manual way and then adding on a convenience, they are parroting social coding |
| 10:43:10 | * | ics joined #nimrod |
| 10:56:38 | * | io2 joined #nimrod |
| 10:58:47 | * | zahary quit (Read error: Connection reset by peer) |
| 11:03:39 | * | zahary joined #nimrod |
| 11:04:25 | * | BitPuffin joined #nimrod |
| 11:20:38 | * | saml_ joined #nimrod |
| 11:40:07 | * | johnsoft quit (Ping timeout: 250 seconds) |
| 11:40:31 | * | johnsoft joined #nimrod |
| 11:45:14 | * | johnsoft quit (Ping timeout: 240 seconds) |
| 11:45:32 | * | johnsoft joined #nimrod |
| 11:46:03 | * | dLog quit (Ping timeout: 240 seconds) |
| 11:55:16 | * | mwbrown joined #nimrod |
| 12:13:43 | * | jj2baile_ joined #nimrod |
| 12:34:24 | * | untitaker quit (Ping timeout: 250 seconds) |
| 12:39:39 | * | untitaker joined #nimrod |
| 12:56:49 | * | mwbrown quit (Ping timeout: 250 seconds) |
| 12:56:59 | * | saml_ quit (Ping timeout: 264 seconds) |
| 13:23:40 | * | flaviu joined #nimrod |
| 13:31:08 | * | darkf quit (Quit: Leaving) |
| 13:54:32 | * | SillyPanda joined #nimrod |
| 14:01:35 | * | mwbrown joined #nimrod |
| 14:02:37 | * | SillyPanda quit (Quit: Textual IRC Client: www.textualapp.com) |
| 14:02:58 | * | SillyPanda joined #nimrod |
| 14:06:35 | * | rahabash joined #nimrod |
| 14:06:48 | * | rahabash left #nimrod (#nimrod) |
| 14:09:57 | * | Fx00F joined #nimrod |
| 14:25:39 | * | askatasuna joined #nimrod |
| 14:27:12 | * | Fx00F quit (Quit: leaving) |
| 14:47:23 | * | kshlm quit (Ping timeout: 264 seconds) |
| 15:09:47 | * | ics quit (Ping timeout: 245 seconds) |
| 15:12:05 | * | ics joined #nimrod |
| 15:14:02 | * | ics_ joined #nimrod |
| 15:15:21 | * | ics__ joined #nimrod |
| 15:16:38 | * | ics quit (Ping timeout: 260 seconds) |
| 15:18:58 | * | ics_ quit (Ping timeout: 260 seconds) |
| 15:27:22 | * | ics__ quit (Ping timeout: 260 seconds) |
| 15:28:01 | flaviu | What is the difference between a symbol and an ident? |
| 15:29:30 | SillyPanda | represents a Nimrod symbol in the compiler; a symbol is a looked-up ident. while an ident just represents a Nimrod identifier in the AST |
| 15:30:18 | flaviu | Thanks, I see |
| 15:31:06 | * | ics joined #nimrod |
| 15:51:02 | * | nnn joined #nimrod |
| 15:51:21 | nnn | Hi! anyone now of any fourier-transform lib for nimrod? |
| 15:51:33 | * | leru joined #nimrod |
| 15:51:38 | flaviu | I think the best way to do it is to wrap a c library |
| 15:52:34 | nnn | Yep, just wanted to check that I had not missed any already available lib |
| 15:52:37 | nnn | Thx |
| 15:53:50 | nnn | Another question: I do not see any library for writing tests. Why is that? |
| 15:55:17 | flaviu | the stdlib has a helper that does reporting and all, but I've heard it sometimes has bugs. Tests just don't seem to be focused upon so much here, which isn't really a good thing |
| 15:55:47 | * | johnsoft quit (Ping timeout: 264 seconds) |
| 15:56:09 | nnn | flaviu, mm I see. Thx |
| 15:57:07 | nnn | Hmm does that mean most code in the stdlib has no tests? :o |
| 15:57:35 | * | johnsoft joined #nimrod |
| 15:57:42 | flaviu | Not comprehensive tests, mostly just "seems to work" sort of tests |
| 15:58:21 | nnn | OK! Thanks. Cheers! |
| 15:58:25 | * | nnn quit () |
| 15:58:51 | flaviu | Tests are usually put at the bottom on the file, inside a `when isMainModule:` block |
| 15:59:16 | * | goobles quit (Ping timeout: 246 seconds) |
| 16:01:10 | * | Jesin quit (Quit: Leaving) |
| 16:05:19 | * | Jesin joined #nimrod |
| 16:11:22 | * | kunev quit (Quit: leaving) |
| 16:19:15 | * | askatasuna quit (Quit: WeeChat 0.4.3) |
| 16:27:33 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 16:41:24 | * | Matthias247 joined #nimrod |
| 16:53:26 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 17:01:36 | * | Matthias247 joined #nimrod |
| 17:08:24 | * | q66 joined #nimrod |
| 17:11:25 | * | adoniscik joined #nimrod |
| 17:20:07 | Araq | what the fuck? |
| 17:20:17 | Araq | we have an excessive test suite |
| 17:20:37 | Araq | last time I checked we have more tests than Microsoft's new C# compiler |
| 17:21:45 | Araq | mostly just "seems to work" kind of tests?! wtf man. |
| 17:22:12 | * | Demos joined #nimrod |
| 17:22:15 | flaviu | Look at json: https://github.com/Araq/Nimrod/blob/devel/lib/pure/json.nim |
| 17:22:32 | flaviu | 40 lines of tests are by no means comprehensive |
| 17:23:22 | flaviu | Now, look at https://bitbucket.org/lyro/strfmt/raw/76664ccd9422e42e112d6139c18bde2aecf6d3cb/strfmt.nim |
| 17:23:22 | flaviu | That is comprehensive |
| 17:23:36 | flaviu | Of course, it could still be better |
| 17:24:44 | Araq | you could also look at json's defect rate and you would see that's sufficiently tested |
| 17:24:48 | flaviu | Also, what I got from his question is that he was looking for library tests, not compiler tests |
| 17:28:38 | Araq | yes. and you answered him properly after he was gone |
| 17:29:33 | flaviu | I couldn't remember if I isMainModule had an is in it, it took a little while to verify that |
| 17:34:11 | Demos | how is idetools --trackDirty supposed to work, I am getting problems with it when I try and use it on a module that is in a subfolder of the project |
| 17:34:26 | * | brson joined #nimrod |
| 17:34:29 | dom96 | yo |
| 17:34:59 | Demos | actually --track fails in the same way |
| 17:36:16 | dom96 | Araq: Who said we have an excessive test suite? |
| 17:37:01 | * | vendethiel quit (Read error: Connection reset by peer) |
| 17:37:09 | Araq | dom96: I do. |
| 17:37:33 | * | Ven joined #nimrod |
| 17:39:28 | Araq | we do have too many features so there are holes left |
| 17:39:30 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 17:39:34 | dom96 | oh |
| 17:39:38 | dom96 | I see |
| 17:39:51 | Araq | but it's excessive nevertheless |
| 17:40:47 | dom96 | I disagree |
| 17:42:20 | * | vendethiel joined #nimrod |
| 17:43:38 | Araq | why? |
| 17:44:39 | dom96 | We have enough, but extra tests always only /help/ |
| 17:45:33 | Araq | I'm pretty sure we have more than 1000 tests, but often I add tests to existing files |
| 17:45:52 | Araq | at what point would *you* call it excessive? |
| 17:49:23 | flaviu | as long as there are still bugs that the test suite does not catch, I consider that test suite incomplete |
| 17:50:01 | Araq | so name a complete test suite for any complex open source project then |
| 17:51:04 | flaviu | SQLite |
| 17:51:28 | flaviu | That I would consider excessive |
| 17:55:24 | * | Jehan_ joined #nimrod |
| 17:57:35 | Araq | ok, fair enough |
| 17:58:11 | Araq | it also has a team of fulltime devs but whatever, it's open source |
| 18:05:35 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 18:12:38 | NimBot | Araq/Nimrod devel ca47a0f PavelVozenilek [+0 ±1 -0]: typo fix |
| 18:12:38 | NimBot | Araq/Nimrod devel 024de25 Andreas Rumpf [+0 ±1 -0]: Merge pull request #1394 from PavelVozenilek/patch-2... 2 more lines |
| 18:12:53 | NimBot | Araq/Nimrod devel 919c136 PavelVozenilek [+0 ±1 -0]: replaced var with let in system.nim... 2 more lines |
| 18:12:53 | NimBot | Araq/Nimrod devel 5c52a56 Andreas Rumpf [+0 ±1 -0]: Merge pull request #1396 from PavelVozenilek/patch-5... 2 more lines |
| 18:15:11 | * | ics joined #nimrod |
| 18:15:19 | * | Ven joined #nimrod |
| 18:20:00 | NimBot | Araq/Nimrod devel 60a2d8a Simon Jakobi [+0 ±1 -0]: Remove unnecessary import |
| 18:20:00 | NimBot | Araq/Nimrod devel 584b6e3 Andreas Rumpf [+0 ±1 -0]: Merge pull request #1382 from sjakobi/patch-1... 2 more lines |
| 18:20:38 | NimBot | Araq/Nimrod devel eafb79b Grzegorz Adam Hankiewicz [+0 ±2 -0]: Hyperlinks echo variants with noSideEffect pragma. Refs #1379. |
| 18:20:38 | NimBot | Araq/Nimrod devel 479b2c6 Andreas Rumpf [+0 ±2 -0]: Merge pull request #1381 from gradha/pr_links_echo_variants... 2 more lines |
| 18:26:58 | NimBot | Araq/Nimrod devel d195f08 Araq [+0 ±1 -0]: fixes #1395 |
| 18:26:58 | NimBot | Araq/Nimrod devel 6219ad6 Araq [+0 ±1 -0]: fixes #1391 |
| 18:26:58 | NimBot | Araq/Nimrod devel e27c675 Araq [+0 ±1 -0]: fixes subtle interaction between closures and 'yield' |
| 18:26:58 | NimBot | Araq/Nimrod devel 725cf0e Araq [+0 ±1 -0]: '[]' for crit bit trees doesn't need the 'var' parameter |
| 18:26:58 | NimBot | 1 more commits. |
| 18:27:11 | Araq | dom96: here you go |
| 18:27:14 | Araq | bbl |
| 18:29:05 | dom96 | Araq: thx |
| 18:30:28 | * | dushan42 quit (Ping timeout: 246 seconds) |
| 18:41:05 | dom96 | Araq: It seems that now the captured future is simply nil |
| 18:41:23 | dom96 | I'm 99% certain its been initialised |
| 18:41:51 | flaviu | How do I get nimrod to use clang? |
| 18:42:16 | flaviu | NM |
| 18:46:53 | * | jh32 joined #nimrod |
| 18:49:44 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 18:50:05 | * | jh32 quit (Remote host closed the connection) |
| 18:51:44 | * | jh32 joined #nimrod |
| 18:53:06 | jh32 | hi |
| 18:53:54 | jh32 | I'm trying to get nimrod 0.9.4 to compile on DragonFly BSD |
| 18:54:18 | jh32 | it fails because of missing execvpe() |
| 18:56:30 | jh32 | There seems to be a special case for MacOSX already, but I don't see how I would bootstrap a modified nimrod version |
| 19:03:01 | * | kunev joined #nimrod |
| 19:23:27 | * | Euclidean_Bevera joined #nimrod |
| 19:23:39 | * | Euclidean_Bevera left #nimrod ("Leaving") |
| 19:28:23 | * | Ven joined #nimrod |
| 19:28:41 | * | kunev quit (Ping timeout: 272 seconds) |
| 19:29:55 | * | kunev joined #nimrod |
| 19:34:13 | Jehan_ | jh32: If you have access to another system where Nimrod builds, you can use "koch csources" to create a bootstrap version. |
| 19:34:15 | * | kunev quit (Ping timeout: 240 seconds) |
| 19:35:58 | Jehan_ | Details: |
| 19:36:23 | Jehan_ | Build koch from koch.nim with "nimrod cc koch.nim" |
| 19:36:52 | Jehan_ | Then: ./koch csource |
| 19:37:07 | Jehan_ | Or: ./koch csource -d:release for the optimized version |
| 19:37:22 | jh32 | ah cool, that should work - but I guess I can't bootstrap 0.9.4 with a 0.9.2 build, right? |
| 19:38:04 | Jehan_ | I haven't tried, it may be possible. |
| 19:38:42 | jh32 | ok, thanks |
| 19:38:42 | Jehan_ | Anyhow, koch csource generates the build directory. |
| 19:39:00 | Jehan_ | Which contains C code for all OS versions (which is why it's fairly big). |
| 19:39:22 | Jehan_ | So, I'd just modify the freebsd version accordingly for this, assuming that the rest of the freebsd stuff works. |
| 19:40:19 | jh32 | yes, it almost works. It just doesn't like because of the missing execvpe symbol |
| 19:40:32 | jh32 | *link |
| 19:40:36 | Jehan_ | Yup, figured as much. |
| 19:40:40 | Jehan_ | Just looking at the code. |
| 19:41:59 | Jehan_ | The modified code should work for FreeBSD, too, since it also has `environ` as a global variable. |
| 19:43:44 | Jehan_ | So, you probably just want in osproc.nim to replace both occurrences of `when defined(macosx):` with `when defined(macosx) or defined(freebsd):` |
| 19:44:39 | jh32 | yes, I'll try that |
| 19:49:07 | flaviu | I don't think that #460, #564, or #863 are show stoppers |
| 19:49:15 | flaviu | at worst, they' |
| 19:49:24 | flaviu | re papercuts |
| 19:49:50 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 19:52:24 | * | Ven joined #nimrod |
| 19:53:06 | flaviu | I'd just like to point out that stuff like #1067 would be fixed for free with my many-pass compiler idea. |
| 20:02:00 | dom96 | showstopper means it should be fixed before next release |
| 20:02:12 | dom96 | IIRC |
| 20:03:02 | flaviu | Might as well mark everything as a showstopper then |
| 20:03:31 | dom96 | You wanna fix every single issue for the next release? |
| 20:03:45 | flaviu | My definition is "Needs to be fixed before the next release or else the compiler is totally unusable" |
| 20:05:41 | flaviu | No, but that's what would happen ideally |
| 20:08:49 | * | leru quit (Ping timeout: 246 seconds) |
| 20:09:14 | Araq | flaviu: and stuff like #1055 would get MUCH worse with your many-pass compiler idea |
| 20:10:22 | Araq | or #1236 |
| 20:10:40 | Araq | or #1258 |
| 20:10:53 | flaviu | Why would 1236 get harder? |
| 20:12:56 | flaviu | #1258 would definitly not get harder, one of the early steps might be to normalize all calls to the metricPrefix(meter, milli, 1e-3) form |
| 20:14:33 | * | kunev joined #nimrod |
| 20:17:21 | flaviu | I definitely feel like I'm not understanding something, everything is complex, although things do not sound complex |
| 20:18:21 | Araq | well it sounds like you're beginning to understand ;-) |
| 20:19:56 | jh32 | Jehan_: it almost works (with master), but the final linking of ./koch boot -d:release fails with 'undefined reference to HEX00_cgenDatInit' |
| 20:20:22 | Jehan_ | Ugh, that looks like a bug. |
| 20:20:37 | Araq | we had that bug before |
| 20:20:40 | Jehan_ | A bug that looks vaguely like … yeah. |
| 20:20:57 | Araq | it means normalizePath or similar doesn't do its job |
| 20:21:13 | Jehan_ | jh32: Which branch are you building from? |
| 20:21:17 | jh32 | master |
| 20:21:24 | Jehan_ | Hmm, can you try devel? |
| 20:21:40 | Araq | this fix is in master though, I'm pretty sure |
| 20:21:44 | Jehan_ | Oh, hmm. |
| 20:21:44 | jh32 | ok, one moment |
| 20:21:48 | Jehan_ | Nevermind then. |
| 20:22:01 | flaviu | Yeah, devel was just merged in a little while ago |
| 20:22:20 | Araq | dom96: well I only looked at the generated C and it creates a closure when the iterator starts |
| 20:22:47 | Araq | do you have a small example now that I can run? |
| 20:22:56 | Araq | we need one for the test suite anyway |
| 20:23:07 | Araq | and I'm too tired to extract a smallish example |
| 20:24:51 | Araq | dom96: are you sure it fails in serveIter? |
| 20:25:32 | dom96 | Araq: yes. The stack trace points to 'echo(f.failed)' |
| 20:27:59 | Araq | er ... well that means it doesn't crash in callback= anymore |
| 20:36:58 | dom96 | yes. Like I said. |
| 20:37:07 | dom96 | <dom96> Araq: It seems that now the captured future is simply nil |
| 20:37:20 | dom96 | Well, I could have been more clear. |
| 20:37:23 | dom96 | It's nil inside the callback. |
| 20:39:28 | Varriount_ | Meep. |
| 20:41:31 | * | Varriount_ is now known as Varriount |
| 20:45:11 | * | kunev quit (Quit: leaving) |
| 20:46:38 | Araq | hi Varriount |
| 20:47:03 | Araq | how's progress on your projects? |
| 20:47:23 | * | q66 quit (Quit: Leaving) |
| 20:47:35 | jh32 | Jehan_: nvm - it works now |
| 20:47:51 | Jehan_ | jh32: Great! :) |
| 20:48:12 | Araq | argh ... must resist ... |
| 20:48:27 | Araq | get a real operating system! |
| 20:48:31 | * | q66 joined #nimrod |
| 20:48:31 | * | Araq couldn't resist |
| 20:49:26 | jh32 | haha, yeah and use rust because it has the bigger community :) |
| 20:49:44 | Araq | hey |
| 20:49:48 | Araq | now that was mean |
| 20:51:07 | jh32 | thanks a lot |
| 20:51:41 | Araq | hmm interesting execvpe is not posix |
| 20:52:38 | Demos | well the most posix complient OS is windows I think (well on paper) |
| 20:52:41 | Demos | (thin paper) |
| 20:52:51 | Araq | but perhaps it will be soon and then I can blame MacOSX and BSD for not following the posix standard again |
| 20:56:57 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 21:03:40 | * | nande joined #nimrod |
| 21:11:04 | Jehan_ | Demos: Umm …. |
| 21:11:41 | Demos | what? |
| 21:11:45 | Demos | well not anymore |
| 21:11:52 | Demos | well sortof not anymore |
| 21:17:17 | * | noam joined #nimrod |
| 21:17:34 | * | xenagi joined #nimrod |
| 21:17:40 | * | boydgreenfield joined #nimrod |
| 21:18:53 | * | q66 quit (Quit: Leaving) |
| 21:22:36 | * | q66 joined #nimrod |
| 21:25:13 | * | brson quit (Ping timeout: 272 seconds) |
| 21:26:15 | Jehan_ | Demos: Let's just start with fork() not being there? |
| 21:26:56 | Araq | cocoa doesn't work with fork(). how's that better? |
| 21:27:56 | * | brson joined #nimrod |
| 21:27:57 | * | brson quit (Client Quit) |
| 21:28:00 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 21:28:05 | * | brson joined #nimrod |
| 21:28:44 | Araq | in fact iirc many things don't work with fork |
| 21:29:35 | flaviu | Araq: What do you think is going on in #1393? |
| 21:30:08 | Jehan_ | Araq: My point was not that fork() is good or bad, but that it's kind of essential for POSIX compatibility. |
| 21:30:15 | flaviu | I've diffed it, I don't think its codegen; clang with -Weverything also doesn't turn up anything important |
| 21:30:24 | flaviu | well, relevent |
| 21:30:44 | Araq | Jehan_: yeah, got your point later |
| 21:30:55 | Araq | *afterwards |
| 21:30:59 | Jehan_ | :) |
| 21:32:57 | Araq | flaviu: run it with -d:useGcAssert -d:useSysAssert |
| 21:33:18 | Araq | I have no idea what's wrong, but in general I'm not too fond of clang |
| 21:33:56 | Araq | in my experience it's much buggier than GCC |
| 21:34:23 | flaviu | That turns up nothing, but valgrind is useful |
| 21:34:59 | flaviu | error is in assign.nim(89) genericAssignAux |
| 21:36:18 | flaviu | root of the call trace is at system.nim(2860) queens. Huh? |
| 21:36:27 | Araq | lol |
| 21:37:12 | Jehan_ | I'm getting: L seq modified while iterating over it [EAssertionFailed] |
| 21:39:33 | flaviu | full output, most of it is noise, but relevent bits are at the end: https://gist.github.com/flaviut/8d31fb50ef367f93fed8 |
| 21:39:38 | Jehan_ | It works with --gc:markandsweep |
| 21:40:31 | flaviu | Seems so, yes, and valgrind also doesn't output hundreds of errors either |
| 21:41:22 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 21:42:13 | Jehan_ | I'd suspect conservative stack scanning, except that that's extremely unlikely to be a problem with no optimizations. |
| 21:42:45 | Araq | actually leaks happen more often in debug builds |
| 21:43:05 | Araq | thanks to lots of crappy pointer like stuff in the stack in debug mode |
| 21:43:26 | Jehan_ | Yeah, leaks, but not premature freeing. |
| 21:43:38 | Jehan_ | The problem isn't running out of memory, it's memory getting corrupted. |
| 21:43:44 | flaviu | Isn't the default reference counting? |
| 21:43:50 | Jehan_ | The out of memory at the end is incidental. |
| 21:43:58 | Araq | yeah |
| 21:44:10 | flaviu | Hmm, release mode also fixes that code |
| 21:47:56 | NimBot | nimrod-code/packages master 3a0fac8 def [+0 ±1 -0]: Add bigints and iterutils |
| 21:47:56 | NimBot | nimrod-code/packages master 6f0320f Dominik Picheta [+0 ±1 -0]: Merge pull request #73 from def-/master... 2 more lines |
| 21:48:38 | * | nande quit (Read error: Connection reset by peer) |
| 21:49:16 | * | Matthias247 joined #nimrod |
| 21:50:47 | * | goobles joined #nimrod |
| 21:52:30 | Araq | thinking about it ... growObj() frees the old sequence and doesn't care if there are other references to it |
| 21:52:44 | Araq | which might as well be the problem here thanks to the swap |
| 21:54:15 | Jehan_ | Looking at the code, I don't see how. |
| 21:54:21 | Jehan_ | That's also what I suspected at first. |
| 21:54:23 | Jehan_ | Hmm. |
| 21:54:30 | Araq | but then it should fail in release too |
| 21:54:35 | Araq | and with gcc |
| 21:55:01 | goobles | nimrooood |
| 21:55:25 | Araq | well it's not hard to find with .injectStmt, I hope |
| 21:56:33 | Varriount | goobles goooooooooobles |
| 21:56:48 | Jehan_ | Hmm, it may not be a problem with solve |
| 21:57:02 | goobles | jehan is right |
| 21:57:08 | Jehan_ | If I first assign the result to a variable and then do the output, it works, too. |
| 21:57:09 | goobles | cause jehan |
| 21:57:58 | goobles | the dark ages of programming |
| 21:58:02 | Jehan_ | Also, putting the output code in a proc fixes it, too. |
| 21:58:14 | goobles | where people use emacs and vim |
| 21:59:35 | goobles | nimrod should go visual so you can visualize what is happening instead of looking at boring text |
| 22:00:02 | Jehan_ | Sure, make a pull request. :) |
| 22:00:09 | Araq | goobles: that doesn't scale |
| 22:00:26 | Araq | goobles: the movie Matrix proved it |
| 22:01:06 | flaviu | goobles: Check out scratch, it does what you want |
| 22:01:16 | flaviu | There's even animated cats! |
| 22:02:31 | Araq | Jehan_: 'answer' is in a location that is below/above the determined start of the stack |
| 22:02:47 | goobles | welp that isn't very impressive flaviu |
| 22:02:58 | Araq | this would explain the behaviour |
| 22:03:01 | Araq | just a guess though, I have no clang installed here |
| 22:03:12 | Jehan_ | Araq: Hmm, that might be it. |
| 22:03:16 | flaviu | Windows noob :P |
| 22:03:17 | * | Trustable quit (Quit: Leaving) |
| 22:03:20 | goobles | dragging blocks around isn't what i mean by visual! |
| 22:04:16 | flaviu | goobles: What about http://www.ni.com/labview/ |
| 22:05:00 | Varriount | gah, flaviu, how dare you post such iniquitus things in this channel! |
| 22:05:08 | * | Varriount slaps flaviu with his glove |
| 22:05:49 | goobles | oh wow I can manage my lab |
| 22:06:02 | goobles | with shitty 1980's visuals |
| 22:06:22 | flaviu | http://www.ni.com/cms/images/devzone/pub/nrjsxmfm912163998723206173.jpg |
| 22:06:31 | NimBot | Araq/Nimrod devel ed68286 Flaviu Tamas [+0 ±1 -0]: Fix #1392 |
| 22:06:31 | NimBot | Araq/Nimrod devel dcf1425 Andreas Rumpf [+0 ±1 -0]: Merge pull request #1399 from flaviut/patch-1... 2 more lines |
| 22:06:36 | flaviu | Nice and maintainable! |
| 22:06:50 | goobles | looks like some of the blueprints i've seen in UE4 |
| 22:07:04 | Varriount | Plus, it's all proprietary! |
| 22:07:33 | Araq | "I currently cannot put my workspace anywhere but C:\ because windows can't handle file names that long. This is way more funny now." |
| 22:07:53 | Araq | yup, I have the same problem |
| 22:07:53 | goobles | wha? |
| 22:08:00 | Varriount | Araq: What's that from? |
| 22:08:07 | Araq | http://www.reddit.com/r/programming/comments/2bdtjz/java_developers/ |
| 22:09:45 | flaviu | Araq: Boot into linux, linux follows the NTFS spec |
| 22:10:07 | flaviu | Amazing, windows xp uses triple DES for encryption |
| 22:10:54 | Araq | flaviu: why would I do that? |
| 22:11:20 | flaviu | Because then you would never run into too-long file names |
| 22:11:29 | goobles | he isn't using java its ok |
| 22:11:52 | goobles | i've never seen that before and I use windows |
| 22:12:05 | flaviu | I've seen it plenty of times |
| 22:12:13 | flaviu | admittedly, mostly with Java |
| 22:12:30 | flaviu | They really love their nested directories there |
| 22:12:43 | goobles | ah, I have only used java once |
| 22:12:48 | goobles | for about a day |
| 22:12:59 | goobles | not my thing- |
| 22:13:01 | Varriount | flaviu: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath |
| 22:13:37 | Araq | flaviu: I consider it a feature that there is a 260 character limit for file paths |
| 22:14:11 | flaviu | pointless limitations a feature? ok... |
| 22:14:26 | Varriount | Actually, the real limit is somewhere around 32,767 |
| 22:14:41 | Varriount | If you're using the api right. |
| 22:14:56 | Araq | Varriount: yes but various tools don't |
| 22:15:12 | goobles | just don't nest the fuck out of shit |
| 22:15:22 | flaviu | Just use linux, it doesn't suck |
| 22:15:36 | goobles | the home of emacs and vim |
| 22:15:45 | Varriount | flaviu: Windows doesn't suck either. |
| 22:15:47 | Araq | flaviu: in theory it prevents idiots from coming up with these insane nesting levels |
| 22:15:50 | flaviu | And you don't have to spend your whole day rearanging windows on top of each other |
| 22:16:21 | Araq | yeah, you can spend your whole day trying to figure out why X11 keeps crashing |
| 22:16:27 | goobles | click window..shake? |
| 22:16:39 | flaviu | X11 has never crashed for me, lol |
| 22:16:46 | * | NimrodBot joined #nimrod |
| 22:16:53 | Araq | but hey, it's only X11, the kernel continues to run |
| 22:17:05 | Araq | very useful for a desktop OS, that is |
| 22:17:37 | flaviu | goobles: You know how every programming language tends to copy lisp poorly? Every non-tiling window manager tends to copy tiling window managers poorly |
| 22:18:17 | Matthias247 | at work we constantly get mails from the IT about too lang path names that have to be fixed... |
| 22:18:25 | Matthias247 | yeah - it sucks :) |
| 22:21:49 | flaviu | goobles: Also, a 10x more powerful version of that, multiple desktops, is a <meta>4 away for me! |
| 22:22:09 | goobles | multiple desktops, what? |
| 22:22:16 | Demos | 260 chars is not a lot |
| 22:22:23 | Araq | multiple desktops are confusing and unnecessary |
| 22:22:30 | goobles | what doesn't that even mean? |
| 22:22:39 | goobles | you have multipel computers to program on? |
| 22:23:03 | Araq | goobles: it's for the poor people who have only 1 monitor |
| 22:23:04 | Demos | flaviu, windows actually has a similar feature, check out the desktops program in sysinternals |
| 22:23:12 | flaviu | No, I have multiple workspace that I can switch between instantly |
| 22:23:38 | goobles | oh, but you can do that on windows also |
| 22:23:45 | goobles | though not sure about instantly |
| 22:23:56 | Demos | desktops works pretty instant |
| 22:23:56 | goobles | not am I sure why you want that so bad |
| 22:24:08 | Demos | only problem is that you can not move programs between the desktops |
| 22:24:11 | flaviu | goobles: Because I don't have any alt-tab |
| 22:24:15 | Demos | I think they are seperate sessions actually |
| 22:24:20 | * | nande joined #nimrod |
| 22:24:23 | flaviu | Its my sole way of switching windows |
| 22:24:52 | Araq | flaviu: btw awesome work with "nimrod by example" |
| 22:25:04 | flaviu | goobles: http://imgur.com/a/U0prm |
| 22:25:09 | Araq | I only recently skimmed it |
| 22:25:10 | flaviu | Araq: Thanks, appreciate it |
| 22:26:11 | Varriount | Hm. Anyone have ideas on how to fix https://github.com/Araq/Nimrod/issues/813? |
| 22:26:54 | goobles | do you have multiple monitors too? |
| 22:26:58 | Varriount | The problem is that the paths the compiler retrieves from various sources aren't always normalized - they don't always have a trailing slash |
| 22:27:08 | flaviu | goobles: no, just one |
| 22:27:14 | Araq | Varriount: dunno but we need to rework path handling in the compiler |
| 22:27:26 | Varriount | Araq: Howso? |
| 22:29:23 | Araq | because it makes little sense |
| 22:29:37 | flaviu | What's happening at https://github.com/Araq/Nimrod/blob/devel/compiler/sem.nim#L99 |
| 22:29:50 | Araq | when foo imports bar.baz that should be relative to foo's location |
| 22:30:04 | Araq | unless there is an explicit "module override" |
| 22:30:43 | flaviu | I don't think any other language does it relative, that seems fragile |
| 22:31:26 | dom96 | python? |
| 22:31:50 | flaviu | Really? ok, sounds good if someone else has done it first |
| 22:32:02 | Varriount | dom96: If I recall correctly, python does it relative from the main file. |
| 22:35:15 | Araq | well it sounds like a good idea to do it this way |
| 22:35:29 | dom96 | bye |
| 22:35:37 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 22:36:16 | Araq | but I might be wrong |
| 22:36:43 | Araq | flaviu: well I don't know what to explain. the code is pretty obvious and documented |
| 22:37:29 | Jehan_ | Araq: Yeah, I think that the stack bottom isn't initialized to have the right value. |
| 22:38:06 | flaviu | Araq: You can add ranges by putting them in a tuple? |
| 22:38:54 | Araq | Jehan_: I tried multiple times to simply round down the stack bottom to a page boundary but it simply doesn't work |
| 22:39:02 | Araq | it causes random crashes |
| 22:39:29 | Araq | and I have no idea why ... my understanding of virtual memory is that it is completely page based |
| 22:39:45 | Jehan_ | I suspect it goes away with optimization because the function gets inlined. |
| 22:40:03 | Araq | sure optimizations change its stack address |
| 22:40:07 | flaviu | it doesn't seem that the compiler uses that feature, or that its documented anywhere |
| 22:40:43 | Araq | flaviu: what does that even mean? |
| 22:40:56 | Araq | "add ranges by putting them in a tuple"? |
| 22:41:34 | flaviu | sorry, I must be misunderstanding whats going on then |
| 22:42:36 | flaviu | NM, I see whats going on |
| 22:43:32 | Varriount | dom96: ping |
| 22:43:44 | Araq | Varriount: dom96 is asleep |
| 22:43:52 | Varriount | Rats. |
| 22:44:22 | Jehan_ | Round down to a page boundary? You mean round up (on x86 architectures, at least)? |
| 22:45:06 | Araq | up/down have the same meaning when I talk about hardware stacks, yes |
| 22:45:17 | Varriount | I'd like to fix this path bug. Either the sources that make up the search paths need to be filtered into their canonical forms, or excluding a path needs to exclude both versions that have '/' at the end and versions that don't. |
| 22:45:31 | Jehan_ | Heh. :) |
| 22:45:50 | Araq | Varriount: the real question is why the / hurts, not how to normalize it |
| 22:46:25 | Jehan_ | What I'd do is to have the stack frames in order: PreMain -> function that sets stack bottom -> function that calls xxxInit()s |
| 22:46:49 | Jehan_ | Still not guaranteed to be perfectly safe if inlining happens. |
| 22:47:09 | Araq | Jehan_: there have been numerous fixes for this already |
| 22:47:17 | Jehan_ | Araq: Hmm. |
| 22:47:21 | Varriount | Araq: Because the excludeStr procedure that --excludePath ultimately passes paths to is case sensitive and literal minded. |
| 22:47:31 | * | NimrodBot quit (Read error: Connection reset by peer) |
| 22:47:48 | Jehan_ | The problem that I'm seeing right now is that NimMain calls PreMain which calls initStackBottom |
| 22:48:10 | Jehan_ | At this point, the stackbottom is already quite a bit down(or up) the stack. |
| 22:48:33 | * | mwbrown quit (Ping timeout: 240 seconds) |
| 22:48:39 | Jehan_ | Because NimMain() also then calls xxxInit(). |
| 22:49:24 | Araq | NimMain needs to set the stack bottom before doing anything else |
| 22:49:54 | Jehan_ | Not just that. The function that sets stack bottom needs to call the rest of the Nimrod code. |
| 22:50:15 | Araq | yeah good point |
| 22:50:22 | Araq | but this is all very fragile |
| 22:50:25 | Jehan_ | If the function that sets stack bottom is on the same frame level as xxxInit(), it's still unpredictable what happens. |
| 22:50:41 | Araq | simply round up the stack address |
| 22:51:03 | Araq | try it please, maybe you succeed where I failed |
| 22:51:11 | Jehan_ | And what if the stack just happens to wrap? |
| 22:51:19 | Jehan_ | Yeah, I was actually going to try that. :) |
| 22:51:34 | Araq | what do you mean? it "wraps"? |
| 22:53:13 | Jehan_ | I mean, if the current call just went over a page boundary. |
| 22:53:53 | Araq | well, perhaps "round" is not the right word, mask the lower bits is more appropriate |
| 22:54:17 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 22:54:57 | Araq | also it's still *close* to the real stack bottom, we don't use a full page of stack memory to call xxxInit functions |
| 22:55:06 | Araq | well I'm not sure what you mean |
| 22:56:17 | Araq | iirc I also tried adding 16 bytes to the stack bottom but even this failed |
| 22:56:35 | Jehan_ | Yeah, I know what you mean. I was trying to point out the case where a stack frame straddles the page boundary. |
| 22:57:14 | Jehan_ | And I'm not concerned with the Nimrod code doing that, but god knows what the code that calls main() does on various OSes. |
| 22:57:38 | Jehan_ | I seem to remember that at least some OSes store the contents of argv there. |
| 22:57:52 | Araq | yes but it doesn't matter |
| 22:57:57 | OrionPK | hello gents |
| 22:58:07 | Araq | only a segfault matters |
| 22:58:36 | Araq | we can happily access random memory as long as it doesn't cause segfaults |
| 22:59:30 | Araq | hi OrionPK |
| 23:02:58 | Jehan_ | My point was that it then still wouldn't help in getting the correct stack bottom. |
| 23:04:27 | Jehan_ | Okay, with a quick hack it worked. Have to set stackbottom to one word below the page boundary, though. |
| 23:04:38 | Jehan_ | Well, it worked for this one example. |
| 23:05:01 | Jehan_ | Also, it was about 2.3k off the page boundary. |
| 23:05:15 | Araq | humm |
| 23:06:05 | Araq | well I don't understand this |
| 23:06:15 | Araq | why is it 2K off? |
| 23:06:26 | Jehan_ | Let me look what's above it on the stack. |
| 23:07:04 | Jehan_ | (gdb) p &locals |
| 23:07:04 | Jehan_ | $1 = (void * volatile *) 0x7fff5fbff6d8 |
| 23:08:23 | * | ics joined #nimrod |
| 23:08:37 | Jehan_ | Program path, the environment, probably arguments too. |
| 23:11:23 | Jehan_ | Well, one thing that you can probably set stackbottom to is the address of the argc parameter in main. |
| 23:14:19 | Araq | nice idea |
| 23:15:22 | * | mwbrown joined #nimrod |
| 23:16:30 | Jehan_ | In register passing architectures, it'll still duplicate it on the stack. |
| 23:16:36 | * | Utkan joined #nimrod |
| 23:17:05 | Jehan_ | But since it'll call NimMain(), it *should* be at the top stack frame. |
| 23:17:47 | Jehan_ | As additional protection, it may be useful to give NimMain() the noinline attribute on gcc/clang. |
| 23:18:02 | Araq | nah, we already have a protection |
| 23:18:16 | Jehan_ | Against inlining? |
| 23:18:17 | Araq | call setStackBottom twice and it picks the minimum/maximum |
| 23:18:27 | Jehan_ | Ah. |
| 23:19:27 | Jehan_ | Hmm, not sure if that helps against NimMain being inlined, though. |
| 23:19:59 | Araq | well sure noinline fo nimmain helps too |
| 23:20:03 | Araq | *for |
| 23:20:41 | Araq | but the old way wasn't too bad, it works most of the time |
| 23:20:57 | Jehan_ | The alternative is to call NimMain through a volatile pointer to prevent inlining portably. |
| 23:21:23 | Araq | I wouldn't count on this |
| 23:21:24 | * | Jesin quit (Quit: Leaving) |
| 23:21:29 | Jehan_ | Why? |
| 23:21:54 | Araq | iirc volatile doesn't really prevent optimizations |
| 23:22:23 | Jehan_ | Well, in this case it forces the compiler not to make assumptions about the content. |
| 23:22:53 | Jehan_ | So it can't inline, because it doesn't know that it'll still point to NimMain when accessed. |
| 23:22:57 | Varriount | What problem are you guys trying to fix/solve? |
| 23:23:09 | * | Jesin joined #nimrod |
| 23:23:14 | Jehan_ | Varriount: setting the stack bottom for conservative stack scanning. |
| 23:23:35 | Araq | Jehan_: hmm yes, you're right |
| 23:23:58 | Varriount | Jehan_: Isn't that already done? |
| 23:24:09 | Jehan_ | Varriount: There's a bug. |
| 23:24:33 | Araq | but then 'foo = nimMain' is pretty trivial to optimize with global analysis |
| 23:25:10 | Jehan_ | Araq: Yeah, but because volatile it may change spontaneously as far as the compiler is concerned. |
| 23:25:16 | Araq | and it also can prove it never points to a hardware memory mapped address |
| 23:25:48 | Jehan_ | The compiler can't prove *anything* about the content of a volatile variable. It isn't allowed to, per the C standard. |
| 23:26:13 | Araq | contrast that with 'foo = (volatile int*) 0xdeadbeef' |
| 23:27:24 | Araq | well I don't know, volatile has been designed for memory mapped IO |
| 23:27:41 | Araq | and not to prevent *any* optimizations |
| 23:27:47 | Jehan_ | And also to make setjmp() work and a lot of other stuff. |
| 23:27:57 | Araq | yes exactly |
| 23:28:11 | Araq | so the pressure to optimize 'volatile' exists |
| 23:30:38 | Jehan_ | An object that has volatile-qualified type may be modified in ways unknown to the |
| 23:30:38 | Jehan_ | implementation or have other unknown side effects. Therefore any expression referring |
| 23:30:38 | Jehan_ | to such an object shall be evaluated strictly according to the rules of the abstract machine, |
| 23:30:38 | Jehan_ | as described in 5.1.2.3. Furthermore, at every sequence point the value last stored in the |
| 23:30:38 | Jehan_ | object shall agree with that prescribed by the abstract machine, except as modified by the |
| 23:30:38 | Jehan_ | unknown factors mentioned previously. |
| 23:31:41 | Araq | oh come on |
| 23:31:48 | Araq | ++someVolatile |
| 23:32:26 | Araq | can be INC [someVolatile] or someVolatile = someVolatile + 1 |
| 23:32:34 | Araq | 2 accesses vs 1 |
| 23:32:36 | * | darkf joined #nimrod |
| 23:33:30 | Araq | so I see INC [someVolatile] as an optimization |
| 23:33:40 | Araq | which is valid, afaict |
| 23:34:52 | Jehan_ | Hmm, I'll take a stab at an implementation that fixes the stack bottom issue and get back to you tomorrow. |
| 23:35:07 | Araq | but this abstract machine stuff sounds interesting, I should read the newer C standard |
| 23:35:16 | Araq | ok, good night |
| 23:36:48 | * | boydgreenfield joined #nimrod |
| 23:40:34 | * | goobles quit (Ping timeout: 246 seconds) |
| 23:40:48 | Araq | er ... why would you write the excludePath differently from the path you added? |
| 23:41:03 | * | Jehan_ quit (Quit: Leaving) |
| 23:43:06 | Araq | I guess we need to canonicalize every path now |
| 23:43:22 | Araq | bah |
| 23:43:39 | Varriount | Araq: See the headache? |
| 23:43:48 | Araq | Varriount: yup |
| 23:44:10 | Araq | I'd rather remove the --excludepath feature then tbh |
| 23:44:21 | Varriount | Why? It's a useful feature. |
| 23:44:44 | Varriount | Or we could just close the bug as won'tfix |
| 23:44:50 | Araq | no, the whole configuration system is way overblown |
| 23:45:04 | Varriount | Oh? |
| 23:45:48 | Araq | unfortunately it's also very useful |
| 23:46:16 | * | adoniscik quit (Ping timeout: 240 seconds) |
| 23:46:27 | * | Utkan quit (Remote host closed the connection) |
| 23:47:04 | Araq | well we never close bugs as "won't fix" |
| 23:47:29 | Araq | well ok I did it once |
| 23:48:06 | Araq | this configuration stuff is like CSS |
| 23:48:37 | Varriount | Hm. There's an idea. Using CSS to modify nimrod code... |
| 23:48:40 | * | AMorpork quit (Ping timeout: 250 seconds) |
| 23:49:05 | Araq | "Oh I want this feature here for this project and these settings for every project unless I override them later" |
| 23:53:25 | Araq | Varriount: rename excludeStr to excludePath and do some fuzzy comparison to fix it |
| 23:53:50 | Varriount | Ok. Will do. |
| 23:54:15 | Araq | it's not used for anything else anyway |
| 23:54:36 | Araq | and since lists.nim is not part of the stdlib we're free to make it behave |
| 23:54:41 | Varriount | Just curious - why is a linked list used? |
| 23:55:31 | Araq | legacy |
| 23:56:54 | Varriount | I'm going to assume that the compiler can't import things from the stdlib? |
| 23:57:09 | Araq | sure it can and does |
| 23:57:21 | Araq | but the compiler predates the stdlib |
| 23:57:29 | Varriount | Ok, so I can import os.nim and use the cmpPath procedure? |
| 23:57:49 | Araq | forgot that that exists, but sure |
| 23:58:49 | Araq | well cmpPaths does not deal with trailing / |
| 23:59:01 | Araq | so you might want to improve cmpPaths |
| 23:59:25 | Araq | good night |
| 23:59:31 | Varriount | Good night. |
