| 00:12:35 | * | q66 quit (Quit: Quit) |
| 01:54:52 | * | mal`` quit (Read error: Operation timed out) |
| 01:57:58 | * | mal`` joined #nimrod |
| 02:20:22 | * | silven_ joined #nimrod |
| 02:20:32 | * | silven quit (Read error: Connection reset by peer) |
| 08:15:28 | * | XAMPP quit (Read error: Connection reset by peer) |
| 08:21:53 | * | Araq_ joined #nimrod |
| 08:23:23 | * | Araq_ quit (Client Quit) |
| 11:39:53 | * | FreeArtMan joined #nimrod |
| 12:40:57 | * | Trix[a]r_za is now known as Trixar_za |
| 14:07:55 | * | Trixar_za is now known as Trix[a]r_za |
| 15:05:53 | * | q66 joined #nimrod |
| 16:23:27 | * | Vladar joined #nimrod |
| 16:56:48 | * | FreeArtMan quit (Ping timeout: 245 seconds) |
| 17:44:38 | * | XAMPP joined #nimrod |
| 17:58:37 | Vladar | Araq, I did some research about that only-on-windows-bug. Not sure what exactly caused it and why only on windows. Here is minimal code to reproduce it: http://pastebin.com/NK31y7BC |
| 18:02:04 | Araq | Vladar: looks like the known const seq bug to me ;-) |
| 18:04:43 | Araq | it's mostly bad luck it's only triggered on windows then I think |
| 18:05:00 | Araq | however this shouldn't have anything to do with bug #263 |
| 18:08:29 | Vladar | I tried to build latest ver. again and everything went fine. |
| 18:10:36 | Vladar | Also, gcc v4.7.2 too. |
| 18:11:14 | Araq | I may try it on windows myself tonight |
| 19:24:44 | * | FreeArtMan joined #nimrod |
| 19:41:48 | Araq | ping zahary |
| 19:47:15 | * | fowl quit (Ping timeout: 240 seconds) |
| 19:49:20 | zahary | pong |
| 19:49:39 | Araq | I'm implementing the 'export' feature |
| 19:50:10 | Araq | and wonder how to do it; simply adding the identifiers to the current module doesn't work as that would introduce ambiguities |
| 19:50:25 | Araq | # module A |
| 19:50:32 | Araq | import B |
| 19:50:36 | Araq | export B.p |
| 19:50:51 | Araq | p() # amb if we add 'p' to A's symbol table |
| 19:51:23 | Araq | and I don't want to introduce yet another symbol flag |
| 19:51:49 | Araq | so I think 'import A' should look into A's ast for 'export' statements? |
| 19:51:56 | zahary | why is it ambigious? is there another definition of p within A or are the multiple definitions of p within B? |
| 19:52:17 | Araq | well there is a 'p' in A and in B |
| 19:52:27 | zahary | aha, I see |
| 19:53:47 | zahary | why don't you add `exports` list that's stored for the module. it doesn't affect local lookups, but when you import … (just like you proposed actually, reading it now) |
| 19:57:04 | Araq | yeah seems to be the way to go |
| 19:59:42 | zahary | will you also implement expressions like A.B.c (B is an another module exported from A)? |
| 20:00:28 | Araq | not planned :P |
| 20:00:46 | Araq | in fact, 'export B' doesn't export B but all of its public symbols |
| 20:01:14 | zahary | do you dislike it or do you consider it too much work for now? |
| 20:01:18 | * | fowl joined #nimrod |
| 20:01:24 | Araq | never thought about it |
| 20:01:42 | Araq | have no opinion about it, so convince me |
| 20:02:22 | zahary | we discussed it once actually - the first time the issue was brought up |
| 20:02:41 | Araq | channel wasn't logged then :P |
| 20:04:59 | zahary | I made an argument that it could be used as alternative for namespaces. for example, there are number of C++ libraries where you import something like tcp or time and then have nested types such as ip4.address / ip6.address or gregorian.date, etc |
| 20:06:26 | Araq | meh ... I still dislike these arbitrary hierarchies |
| 20:06:49 | Araq | but since I'm apparently the only one, I'll reconsider this |
| 20:07:49 | Araq | everybody seems to like universe.earth.programming.language.nimrod.token.kind.EOF |
| 20:09:18 | zahary | for hypolang I was going to use namespaces to achieve something similar to some of the pragmas (these that serve as directives) |
| 20:09:19 | zahary | instead of {.error: "blah" .}, the system module exports a submodule with these directives as normal magic functions |
| 20:09:19 | zahary | nimrod.error "blah" |
| 20:09:46 | zahary | I can't argue this is better, but I should mention it (I didn't have such pragmas in the design) |
| 20:10:39 | Araq | one reason I dislike this is that '.' is already quite ambiguous; it's easy to implement if you add a skNamespace symbol kind |
| 20:10:55 | zahary | well, we already have skModule |
| 20:11:04 | zahary | that's enough |
| 20:11:11 | Araq | hrm |
| 20:11:17 | Araq | maybe, yeah |
| 20:12:42 | * | FreeArtMan quit (Ping timeout: 264 seconds) |
| 21:10:20 | Araq | oh btw zahary we'll also get warnings about potential race conditions :-) |
| 21:10:54 | Araq | the idea is that any load/store to a 'shared' location that doesn't occur within some lock is racy |
| 21:11:27 | Araq | atomic ops are special cased of course |
| 21:15:39 | zahary | how deep does the analysis go? can I fool the system by using 2 different locks for the same shared location (thus not preventing the race)? |
| 21:17:41 | Araq | yes :-) |
| 21:17:53 | Araq | well I thought about adding an expression to 'shared' |
| 21:18:12 | Araq | and use some alias analysis to determine lock identity |
| 21:18:47 | zahary | nevertheless, sounds good. make sure it also works with scoped locks |
| 21:19:29 | Araq | well my idea is that even a very simplistic approach results in a huge win in practice |
| 21:20:24 | Araq | however you're right, it'd be nice if a lack of a warning would guarantee race freedom |
| 21:20:43 | zahary | yeah, sure. the case I cited is almost diabolic, although with nested locks some "parent" lock may trigger a false-possitive |
| 21:21:00 | Araq | it's possible if you only have global locks and no aliasing |
| 21:21:12 | Araq | then the deadlock analysis can be accurate too |
| 21:26:36 | Araq | I think in practice the big problem is arrays |
| 21:27:01 | Araq | there are lots of index partitions that ensure no sharing occurs at runtime |
| 21:27:39 | Araq | and yet all these a[i] expressions are evil for compile-time analysis ;-) |
| 21:28:36 | Araq | so I thought about a partition() built-in |
| 21:29:08 | Araq | but I think all this requires dependent typing to work |
| 21:29:32 | zahary | what is this partition built-in exactly? |
| 21:29:45 | Araq | dunno ;-) |
| 21:30:10 | Araq | partition(a, i, j, k) --> (b, c, d) where b,c,d are uniquely typed slices |
| 21:31:08 | zahary | these are the "border indices"? |
| 21:31:16 | zahary | a, i, j, k |
| 21:31:27 | Araq | a is the original array |
| 21:31:33 | Araq | i,j,k are some borders |
| 21:31:49 | Araq | you can check the borders at runtime doesn't matter much |
| 21:32:54 | zahary | I've read the region types writings for rust, they cover similar problems |
| 21:33:29 | zahary | also, microsoft have a new C++ compiler features for massive data parallelism that define similar types |
| 21:33:55 | zahary | http://msdn.microsoft.com/en-us/library/hh265137.aspx |
| 21:35:25 | Araq | yeah I think chapel does something similar |
| 21:38:01 | Araq | one problem is that these uniquely typed arrays are need a new form of polymorphism |
| 21:38:38 | Araq | it's essentially the "taint" problem |
| 21:38:52 | Araq | if the input is tainted the output should be too |
| 21:39:03 | Araq | it comes up again and again |
| 21:39:10 | Araq | units of measure is another example |
| 21:45:07 | zahary | I understand the taint problem, and I see how it applies for everything (array views included), but why do you consider units of measure a special instance of it? also, array views (partitions) seem to be mostly about aliasing. the tainting aspect comes orthogonal to the aliasing aspect |
| 21:46:19 | zahary | aliasing and lifetime |
| 21:47:04 | Araq | F# has some nice feature for units of measure and they have some type inference for it |
| 21:47:14 | Araq | that looks like it solves the taint problem too |
| 21:47:29 | Araq | but I could be wrong |
| 21:48:17 | Araq | f: string?tainted -> string?tainted |
| 21:48:36 | Araq | `+`: int?measure * int?measure -> int?measure |
| 21:48:57 | Araq | where ? means "optionally with this attribute" |
| 21:49:05 | zahary | I have studied some C++ libraries for units of measure as it's an interesting problem for me. basically, C++ features (static types that don't change over time) are enough to solve the problems |
| 21:50:14 | zahary | hmm, but what is measure here? just a flag? measure is about conversions of units and catching errors of incompatible units |
| 21:50:34 | Araq | yeah I know, but for a start s+s yields s |
| 21:50:42 | Araq | (s = second) |
| 21:51:21 | Araq | and s + no measure is a type error |
| 21:53:22 | * | Vladar quit (Quit: Leaving) |
| 21:58:01 | * | gradha joined #nimrod |
| 22:05:45 | Araq | btw have you look at the 'not nil' stuff yet? |
| 22:10:25 | zahary | not yet |
| 22:10:35 | zahary | I read the docs about it |
| 22:10:46 | Araq | yay XD |
| 22:11:07 | Araq | 1) 'nil' is the wrong default |
| 22:11:22 | Araq | 2) the implementation is wrong |
| 22:11:44 | Araq | it sets some type flag, but if you do 'string not nil' than it modifies the string type |
| 22:11:48 | Araq | everywhere |
| 22:12:06 | zahary | oops :) |
| 22:12:32 | Araq | a tyNotNil(tyString) construct would have prevented that |
| 22:12:49 | Araq | but then we'd need to skip over tyNotNil almost everywhere |
| 22:13:10 | Araq | these type graphs are really hard to design |
| 22:14:33 | Araq | 'shared' has the same problem |
| 22:15:11 | Araq | one solution is to only allow them in a 'type' section so it's always an annotation for a named type |
| 22:15:28 | Araq | i.e. we know we deal with a fresh type object |
| 22:16:21 | Araq | but it's annoying for the programmer |
| 22:16:53 | zahary | what's root of the problem with not nil infecting the original string type? the caching done in systypes? |
| 22:17:10 | Araq | for any structural type we can create a copy before setting the flag |
| 22:17:25 | Araq | but for a nominal type this doesn't work |
| 22:17:44 | Araq | so 'not nil' can be fixed but it illustrates the general problem |
| 22:18:26 | Araq | (and yeah we can copyType tyString too and set the flag in the copy only) |
| 22:20:15 | zahary | let's imagine that a "not nil" is compileTime property of the type. we plan to allow overloading based on compile time properties so it's the same problem. clarify a bit more why it doesn't work for nominal types |
| 22:22:38 | Araq | well if you have A{.prop.} and A where A is an object type |
| 22:22:55 | Araq | you want these to map to the same C struct for instance |
| 22:23:20 | Araq | so the plan was to have 2 A type objects in the compiler with same ID |
| 22:24:02 | Araq | however large parts of the compiler can't work this way |
| 22:24:40 | Araq | it's often more handy to store stuff in the A itself instead of in lots of mappings type-ID -> stuff |
| 22:25:12 | zahary | ok, I have worked on a design for compileTime properties a bit btw. indeed tyNotNil is analogous to what I have in mind. I would introduce a single tyTypeView (if we use ATS terminology or tyTypeState if we use rusts) and that's what have to be skipped in some places as you said |
| 22:25:39 | Araq | yeah that should work |
| 22:25:51 | Araq | and a single tyTypeView is fine with me |
| 22:26:06 | Araq | but the proliferation of these abominations needs to stop ;-) |
| 22:26:21 | Araq | maybe we can generalize some existing type property |
| 22:26:48 | zahary | not nil is a good example of built-in compileTime property for the ref types |
| 22:30:01 | Araq | perhaps but 'not nil' deserves special treatment in the type system |
| 22:38:24 | gradha | how are import naming conflicts resolved? say I want to name strutils a module in my program and want to import that, or the one provided by nimrod libraries in different files |
| 22:39:43 | Araq | from x import `%` |
| 22:39:51 | Araq | import y except `%` |
| 22:39:59 | Araq | or simply: |
| 22:40:08 | Araq | x.`%`(2, 3) |
| 22:40:33 | Araq | imports are optimistic :P |
| 22:40:51 | Araq | both symbols are imported and overloading resolution figures it out |
| 22:41:19 | Araq | or if it's a type or variable, an error is raised if you actually use the symbol in your code |
| 22:41:19 | gradha | that's not what I was meaning |
| 22:41:32 | gradha | I have a strutils.nim file in my project |
| 22:41:48 | gradha | when I type "import strutils", does my file get imported or the one in nimrod's library? |
| 22:41:48 | Araq | well too bad for you then |
| 22:41:57 | Araq | your file |
| 22:42:10 | Araq | as it's closer to your main.nim file |
| 22:45:34 | * | silven_ quit (Ping timeout: 265 seconds) |
| 22:47:35 | Araq | wow I just noticed, I stopped reading your question after the question mark |
| 22:48:41 | gradha | that's all right, question marks terminate sentences after all |
| 22:49:14 | Araq | well I take it as a sign I should go to sleep |
| 22:50:11 | gradha | ouch, nimrod just crashed compiling |
| 22:51:18 | Araq | if only there would be a way to declare a crash to be a feature ... |
| 22:51:39 | gradha | bah, remember I'm on mac, it's surely a mac problem |
| 22:51:47 | gradha | maybe not enough white pixels or something |
| 22:52:04 | Araq | ancient GCC version :P |
| 22:52:36 | gradha | that's new, especially since I have to compile with clang or it doesn't work at all |
| 22:52:57 | Araq | well there is a known bug that could be the cause for it |
| 22:53:24 | gradha | right now I was playing with importobjc |
| 22:53:32 | gradha | when used on a proc in the same module, it works |
| 22:53:40 | Araq | the fix would be easy if I could get over adding a 8/16 byte header to constant sequence/string |
| 22:53:45 | gradha | when I move the proc along the type to a different module, the module referencing it doesn't like it |
| 22:54:02 | Araq | but instead I'm thinking about some way to avoid that :P |
| 23:02:22 | gradha | hmmm... this is bad, I compiled in debug, but get no stack trace or anything |
| 23:03:50 | gradha | I only get "Error: execution of an external program failed" |
| 23:09:10 | zahary | this means that the C compiler produces an error |
| 23:09:30 | zahary | you can see the error by giving —parallelBuild:1 on the command line |
| 23:10:23 | zahary | the printing of errors should really be fixed at some point, but that's a work-around for now |
| 23:10:56 | gradha | ok, so that's what it was |
| 23:11:23 | gradha | yes, the compiler was failing because I was using bad parameters |
| 23:11:44 | Araq | what "bad parameters"? |
| 23:11:54 | gradha | trying to compile objc as c |
| 23:12:40 | gradha | got used so much to "nimrod c whatever" that it seems I have it hardcoded |
| 23:15:36 | Araq | he he alright |
| 23:15:51 | gradha | ah, and just found out the other problem I was having is due to naming conflicts |
| 23:16:00 | gradha | I had defined a NSString type with a cstring proc |
| 23:16:15 | gradha | so when that is in another module the "incorrect" cstring gets used |
| 23:16:23 | gradha | solved by renaming |
| 23:17:31 | gradha | lovely, now recompile nimrod in release... |
| 23:24:19 | gradha | wow, amazing xcode quality software, I added two nim files to the project, one works, the other is shown in red and doesn't even open |
| 23:28:06 | * | gradha quit (Quit: gradha) |
| 23:37:34 | Araq | good night guys |