| 00:25:52 | * | apriori_ quit (Quit: Konversation terminated!) |
| 05:05:46 | Zor | Araq: ping |
| 07:53:11 | * | XAMPP quit (Ping timeout: 260 seconds) |
| 08:02:58 | * | XAMPP joined #nimrod |
| 09:13:40 | * | gour joined #nimrod |
| 09:20:39 | gour | morning |
| 09:23:09 | gour | i was chatting with the guy working on modula-2 r10 spec/compiler yesterday and he mentioned that they replaced variant records in r10 with oberon-like extended types, so i wonder if this is same as nimrod's object types? |
| 09:23:53 | gour | in r10 it goes like: TYPE BaseType = RECORD a, b, c : INTEGER END; TYPE ExtendedType = RECORD ( BaseType ) d, e, f : INTEGER END; |
| 09:28:28 | Araq | gour: pretty much yes, it's called "inheritance" |
| 09:29:05 | gour | you mean this example: TStudent = object of TPerson ? |
| 09:29:13 | Araq | yes |
| 09:29:20 | gour | :-) |
| 09:29:28 | Araq | and btw I know the Modula-2 guy ... ;-) |
| 09:29:52 | gour | heh, he is tirelessly working to revive modula-2, right? |
| 09:30:13 | Araq | Zor: you keep pinging me when it's 5 o'clock in the night ... |
| 09:30:24 | gour | otoh, i wonder how have you manage to pack so many modern features in your language? i'm really impressed!! |
| 09:31:32 | gour | Araq: he made a good point that Ada is kind of C++ of Pascal, iow. Ada is too big...otoh, nimrod is modern language, compiler is available today, while R10 won't be ready (if) before mid 2013 |
| 09:31:58 | gour | moreover, size of modula-2 community does not seem to be much bigger than here :-) |
| 09:32:05 | gour | (at least, irc-wise) ;) |
| 09:32:41 | gour | maybe Zor consider it's 5 o'clock in the morning :-D |
| 09:32:57 | Araq | that's because modula-2 is dead :P |
| 09:33:06 | * | gour nods |
| 09:33:40 | gour | some people there told me about dylan/mercury...some does things in oberon(2)... |
| 09:34:08 | gour | i mentioned nimrod, although some believe that "there is no need for another imperative lang" :-) |
| 09:35:01 | gour | i went through the manual, but cannot say i grok generics/templates/macros, but there is plenty of things to do without them |
| 09:35:37 | Araq | there is hardly ever a "need" for anything new, especially when it's about new programming languages |
| 09:36:02 | Araq | there was no need for C++ either, C existed before |
| 09:36:03 | gour | right |
| 09:36:22 | Araq | there is no need for Ocaml, ML existed before, etc. |
| 09:39:27 | gour | koch is described as "Maintenance program for Nimrod", babel is, afaict, package manager, so what is build-system for nimrod projects? |
| 09:39:59 | Araq | there is none, it's integrated into the compiler |
| 09:43:46 | gour | so, is it capable to e.g. build complete projects consisting of: included 3rd party C-lib, run c2nim on the header, build bindings, build custom libs written in nimrod, build gui application using those libs and build manual (html/pdf) from reST/Sphinx sources? |
| 09:44:07 | Araq | no :P |
| 09:44:41 | Araq | but then what's the point? the 3rd party C-lib uses autoconf + make or scons or ... |
| 09:44:44 | gour | huh...so what do you recommend for such use-case or you have something on your todo.txt? |
| 09:45:10 | gour | well, in my case 3rd party lib just uses Makefile |
| 09:45:49 | gour | the point is to have ability to completely build the project using one build tool |
| 09:46:28 | Araq | well *I* would write a small program in Nimrod that executes what's necessary |
| 09:47:07 | Araq | and this script would be bound to the project |
| 09:47:26 | Araq | "one build tool to rule them all" -- I don't believe in that |
| 09:47:30 | * | gour quit (Disconnected by services) |
| 09:47:33 | * | gour_ joined #nimrod |
| 09:48:04 | * | gour_ is now known as gour |
| 09:48:45 | * | gour reads backlog |
| 09:49:24 | gour | well, waf/scons/cmake...can do it, isn't it? |
| 09:49:46 | Araq | yes |
| 09:50:09 | Araq | so write some module so that scons/cmake support nimrod |
| 09:50:25 | Araq | btw I used scons and will never touch it again |
| 09:50:29 | gour | yeah, nimrod support for one of those is required |
| 09:50:44 | gour | he he |
| 09:50:58 | gour | i played a bit with waf as well |
| 09:51:19 | Araq | and the cmake guys can't even write a parser (wtf? whitespace before ';' ) |
| 09:51:26 | gour | maybe, tup would be more suitable for you...felix has its own fbuild, right? |
| 09:51:47 | gour | cmake 'lang' is beaut..err. horrible |
| 09:52:58 | Araq | I don't know 'tup' or 'waf' |
| 09:53:02 | gour | i understand, there are not so many bigger nimrod projects around requiring complete build tool, but we hope the time will arrive for it |
| 09:53:16 | gour | tup - http://gittup.org/tup/ |
| 09:53:46 | gour | waf is/was fork of scons trying to fix it when KDE was switching their build system and scons was too slow |
| 09:53:59 | gour | now, it's probably complete rewrite |
| 09:54:20 | gour | http://code.google.com/p/waf/ |
| 09:55:29 | Araq | anything python-related is out of question :P |
| 09:55:41 | gour | i believe it would be quite easy to add nimrod support to waf, but have to investigate about tup...when considering ada, i thought GPS build system will be sufficient |
| 09:55:51 | Araq | so I guess, yeah, we need our own build tool :P |
| 09:56:21 | gour | why - "Nimrod combines Lisp's power with Python's readability and C's performance." :-) |
| 09:56:49 | Araq | oh it would of course use nimrod's syntax |
| 09:57:07 | Araq | in fact, it would likely be just a library for nimrod |
| 09:57:13 | gour | i also believe that something simpler/better than cmake/scons/waf is possible...will take closer look at tup, at least, as intermed. workaround |
| 09:57:36 | Araq | fowl created some DSL for building things |
| 09:57:38 | gour | have you seen Bento? using declarative syntax similar to haskell's cabal? |
| 09:58:05 | gour | http://cournape.github.com/Bento/ |
| 09:59:33 | gour | tup is mostly C |
| 10:01:16 | Araq | gour: http://forum.nimrod-code.org/t/67 |
| 10:04:06 | Araq | that's how it should be done for nimrod ;-) |
| 10:04:30 | Araq | however having a nimrod interpeter for that would be sweet |
| 10:09:27 | * | gour nods |
| 12:41:33 | * | apriori_ joined #nimrod |
| 12:49:45 | apriori_ | btw., has there been any progress with proxies? |
| 13:46:00 | Araq | apriori_: well I played with a couple of ideas ... |
| 13:49:20 | Araq | most promising seems to be to be able to overload the '.' "operator" |
| 13:49:22 | * | Trix[a]r_za is now known as Trixar_za |
| 13:53:16 | apriori_ | yeah.. |
| 13:53:45 | apriori_ | question is.. would I be able to somehow get the string behind the '.' then.. |
| 13:54:01 | Araq | of course ;-) |
| 13:54:03 | apriori_ | if that'd be possible (or something similar), I could implement vector swizzeling easily |
| 13:54:34 | Araq | I'm aware :P |
| 13:54:46 | apriori_ | btw.. if you happen to have a minute.. seems that I have found another bug with generic type aliases |
| 13:54:52 | apriori_ | at least, it seems so.. I've no other idea |
| 13:55:12 | apriori_ | https://gist.github.com/4318437 |
| 13:55:17 | Araq | yeah I think there is 1 test left that doesn't work |
| 13:56:07 | apriori_ | you won't find any real use of TMatrixArray and TVectorArray in there, besides the aliases.. but I'd prefer to be able to use them in converters etc. |
| 13:56:24 | apriori_ | to save the constant typing of array[M, array[N, T].. which looks noisy :P |
| 13:57:51 | Araq | well yeah, I don't mind it |
| 13:57:57 | Araq | so what's the problem? |
| 13:58:13 | apriori_ | the error message is in the source comment |
| 13:58:27 | apriori_ | when changing the StaticMatrix declaration to use any of the mentioned aliases, compilation will fail |
| 13:59:06 | apriori_ | iterator `..`*[S, T](a: S, b: T): T {.inline.} = |
| 13:59:07 | apriori_ | ## An alias for `countup`. |
| 13:59:09 | apriori_ | var res: T = T(a |
| 13:59:14 | apriori_ | the last line of the paste is system 1255 |
| 13:59:28 | apriori_ | hrm, it should have been: |
| 13:59:31 | apriori_ | var res: T = T(a) |
| 14:00:10 | Zor | Araq: does nimrod have global constants (or just global variables with initializers for that matter)? |
| 14:00:51 | apriori_ | Zor: http://nimrod-code.org/manual.html#global_782501908 |
| 14:02:13 | Zor | so in the compiled C, where does the compiler put the actual initialization? |
| 14:03:20 | Araq | apriori_: yeah looks like a bug; my bet is the compiler is confused about range[0..1] vs 0..1 again? |
| 14:03:39 | apriori_ | I have no idea |
| 14:03:52 | Araq | Zor: the compiler emits 'init' functions that are inserted into 'main' |
| 14:04:12 | Zor | what do you do for shared libs? |
| 14:05:41 | Araq | Zor: __attribute__((constructor)) |
| 14:06:12 | Zor | makes sense, though do all the compilers you support have an equivalent of that? |
| 14:06:26 | Araq | on Linux, yes |
| 14:06:39 | Araq | on windows there are other means but I forgot :-) |
| 14:07:18 | Zor | what about os x? |
| 14:07:43 | apriori_ | Araq: creating a bug report + gist link |
| 14:08:36 | Araq | apriori_: thanks |
| 14:08:41 | Araq | Zor: http://stackoverflow.com/questions/9759880/automatically-executed-functions-when-loading-shared-libraries |
| 14:08:50 | Araq | works on mac os X too afaik |
| 14:09:30 | Zor | I see |
| 14:09:45 | Zor | do you currently implement this stuff on windows or is that a todo thing? |
| 14:09:56 | * | gradha joined #nimrod |
| 14:12:37 | Araq | Zor: DLLs have currently some issues with RTTI but apart from that it all works |
| 14:12:49 | Araq | on mac, windows, linux and bsd |
| 14:13:18 | Araq | we can even emulate thread local storage for the dreaded macosx |
| 14:13:31 | Araq | but I heard macosx finally supports thread local storage |
| 14:13:35 | apriori_ | and freebsd :P |
| 14:13:39 | apriori_ | If I'm not wrong |
| 14:13:56 | Araq | bsd implies freebsd ;-) |
| 14:14:23 | apriori_ | I meant TLS |
| 14:14:49 | apriori_ | but, yeah.. macosx is pretty much bsd'ish.. |
| 14:23:33 | gradha | the tup examples on their website are really wonderful, verbose and full of colors |
| 14:24:17 | apriori_ | gradha: on whose website? |
| 14:24:31 | gradha | http://gittup.org/tup/ex_a_first_tupfile.html |
| 14:24:52 | gradha | the nice thing is they work on an example and show colored diff-like output at each step |
| 14:25:13 | gradha | so it's really easy to follow with the embedded code rather than whip out a terminal and start copying/pasting |
| 14:27:22 | gour | gradha: it seems also that adding Nimrod support to it is quite straightforward, unlike cmake/scons |
| 14:30:27 | Araq | gradha: you can do that with nimrod's documentation system |
| 14:30:40 | Araq | it only requires to know about undocumented features :P |
| 14:31:09 | gradha | ah, lovely undocumented features |
| 14:31:28 | gradha | I could learn html too, I guess |
| 14:32:02 | Araq | I think you can do `text here`:mytag: and then you get in the HTML class="mytag" for the 'text here' |
| 14:32:06 | Araq | and then you can CSS it |
| 14:33:17 | Araq | oh and btw, documenting the documentation generator would be nice; please do it :-) |
| 14:38:38 | apriori_ | Araq: and more bugs :P |
| 14:38:53 | apriori_ | Araq: https://github.com/Araq/Nimrod/issues/285 |
| 14:38:54 | apriori_ | Araq: https://github.com/Araq/Nimrod/issues/286 |
| 14:39:34 | Araq | apriori_: The code is working, if one replaces the call to isAnyFloat[T] with isAnyFloatT |
| 14:39:45 | apriori_ | grr... |
| 14:39:46 | Araq | github ate your () ? |
| 14:39:48 | apriori_ | damn markup |
| 14:40:32 | apriori_ | grr.. no preview for edits :/ |
| 14:40:32 | Araq | you should really use a .compiletime proc instead of a template here ... |
| 14:40:49 | * | q66 joined #nimrod |
| 14:40:49 | apriori_ | yeah, maybe.. but anyway the compiler shouldnt crash :P |
| 14:41:04 | Araq | of course |
| 14:41:28 | apriori_ | but about the missing ().. should that be valid? |
| 14:41:40 | Araq | it shouldn't |
| 14:41:58 | apriori_ | ok |
| 14:42:01 | Araq | you can't invoke functions with 0 args without () |
| 14:42:18 | apriori_ | yeah, makes sense |
| 14:46:48 | Araq | gradha: you need to use your exported variables, then they should end up in the header file |
| 14:47:06 | Zor | Araq: yeah newer OS Xs have native TLS |
| 14:47:18 | Zor | clang supports __thread and everything there afaik |
| 14:48:21 | Araq | we should change the default config then I guess |
| 14:48:34 | gradha | will test that |
| 14:48:51 | gradha | now I actually have a real case using it |
| 14:49:56 | Araq | I can fix it, but I'm too lazy to test it :P |
| 14:50:10 | Araq | or we live with the bug :P |
| 14:50:19 | gradha | however, I wanted to export globals to C, so they may not end up being used directly in nimrod |
| 14:50:50 | Araq | why would you ever want to do that? |
| 14:51:06 | gradha | convenience of having related stuff together |
| 14:51:14 | gradha | I'm writing notification code from nimrod into C |
| 14:51:21 | Araq | fine, I'm fixing it then |
| 14:52:39 | gradha | it's not a priority, I'm using a workaround |
| 14:53:09 | Araq | too late :P |
| 14:56:14 | gradha | this is definitely wrong, after cleaning the trashcan the filesystem reports 2GB less of free space |
| 14:56:25 | gradha | looks like time for another reboot to keep sane |
| 14:57:46 | apriori_ | Araq: ah well, another minor issue: https://github.com/Araq/Nimrod/issues/283 |
| 14:58:06 | Araq | apriori_: I saw it, yeah |
| 14:58:22 | Araq | the parser has some issues :P |
| 14:58:27 | apriori_ | yeah |
| 14:58:38 | Araq | due to its "evolution" |
| 14:58:48 | apriori_ | hehe |
| 14:59:05 | apriori_ | a few changes here and there.. its easy to overlook something |
| 15:00:39 | Araq | a parser generator would be sweet but there are none that support indentation based parsing :P |
| 15:01:39 | Araq | and it's still clean enough to pass as a spec *cough* |
| 15:03:06 | Araq | gradha: what do you have in mind with #265 ? |
| 15:03:18 | Araq | [10 NSMutableArray ...] wtf?? |
| 15:03:44 | gradha | I realized later the example is wrong |
| 15:04:05 | gradha | ah, no that part, that's what the current pragma generates |
| 15:05:43 | gradha | in objc you tend to have the alloc+init chaining, but there are also convenience class methods which return autoreleased objects |
| 15:06:04 | gradha | for example, there's + (NSMutableArray*)arrayWithCapacity:(int)amount; |
| 15:06:25 | gradha | not sure if that's the real prototype, but should be similar |
| 15:06:50 | Araq | he he, nobody can remember objc's clusterfuck of a syntax |
| 15:07:00 | gradha | the current objc pragma presumes the first parameter is the self object, which fails in these class methods |
| 15:07:45 | apriori_ | I know why I never ever touched Obj-C .. after only taking a look at its wikipedia page |
| 15:07:54 | apriori_ | stringByAppendString.. wtf? :P |
| 15:08:12 | gradha | since I learned of emit and played with some macros you can close the issue, I'll come back and fix it myself if I need to |
| 15:08:28 | gradha | or ask later for help if I'm unable to |
| 15:08:55 | gradha | At the moment I have a helper file with: |
| 15:08:56 | gradha | proc newNSMutableArray*(capacity: int): NSMutableArray {. |
| 15:08:57 | gradha | NoStackFrame, inline.} = |
| 15:08:58 | gradha | ## Returns a new mutable array with the specified capacity. |
| 15:08:59 | gradha | {.emit: """return [NSMutableArray arrayWithCapacity:`capacity`];""".} |
| 15:09:40 | gradha | so it works, and that's enough for me at the moment, close the issue if it's distracting |
| 15:11:15 | gradha | BTW, I can confirm you that declaring an exported global in nimrod and using it in nimrod generates its extern |
| 15:12:27 | gradha | so https://github.com/Araq/Nimrod/issues/277 would only be an issue for nimrod code exporting globals to be used from C |
| 15:13:33 | gradha | apriori_: the naming rules of objc were written by a schizofrenic who contradicts itself |
| 15:13:47 | apriori_ | gradha: hehe |
| 15:13:48 | gradha | like "please write code to 80 columns", then "please name methods with at least 80 characters or more" |
| 15:14:48 | gradha | and their indentation is really fucked up, with xcode borking it every time I try to use it, mixing spaces/tabs and who knows what else |
| 15:15:05 | apriori_ | then it' |
| 15:15:10 | gradha | not even their starting templates have clean "only spaces" or "only tabs" |
| 15:15:13 | apriori_ | then it'll look like the code of my professor :P |
| 15:16:13 | gradha | I've just learned to silently walk away from anybody claiming their naming conventions are good |
| 15:19:07 | Araq | gradha: I fixed #277 anyway |
| 15:19:22 | gradha | cool, I was just going to ask for a related feature |
| 15:19:27 | Araq | and now I'm looking for the struct body bug |
| 15:19:40 | Araq | but can't find the bug number :P |
| 15:20:03 | Araq | these bugs really need to be grouped by frontend/backend at least |
| 15:20:06 | gradha | https://github.com/Araq/Nimrod/issues/238 ? |
| 15:20:18 | Araq | yep that's it |
| 15:29:18 | gradha | I'm wondering if you can transform nimrod literals directly to objc literals, say I have code like "var a = objcLiteral("test")" which turns into "NSString *a = @"test";" |
| 15:30:12 | gradha | I have new objcLiteral implemented as a proc emitting a call to a new NSString |
| 15:30:29 | Araq | I don't think you can do that |
| 15:32:17 | Araq | oh wait, maybe you can :P |
| 15:33:27 | Araq | template objcLiteral(x: cstring): expr = {.emit: "@`x`".} # try this |
| 15:33:37 | Araq | but .emit can't be an expression I think |
| 15:34:22 | gradha | in the case of globals it doesn't think it would work either, it seems the global is declared and initialized somwhere in nimrod's main |
| 15:34:39 | gradha | s/think/look |
| 15:36:12 | Araq | #define OBJC_LIT(x) @x |
| 15:36:48 | Araq | proc objcLiteral(s: cstring): NSString {.importc: "OBJC_LIT".} |
| 15:37:18 | Araq | but I dunno if objective C's preprocessor allows that |
| 15:42:59 | gradha | if it's for the c preprocessor I'll find out |
| 15:48:14 | apriori_ | meh :/ |
| 15:48:16 | apriori_ | Error: ambiguous call; both vector.inverse(matrix: TMatrix3x3[T]): TMatrix3x3[T] and vector.inverse(matrix: TMatrix2x2[T]): TMatrix2x2[T] match for: (TMatrix2x2[float] |
| 15:48:39 | apriori_ | seems like an OR error |
| 15:50:43 | gradha | Araq: ok, the OBJC_LIT trick works if you define it as OBJC_LIT(X) (@"" #X) |
| 15:51:01 | gradha | that performs a concatenation of the parameter as a literal to the empty literal, so it works out |
| 15:53:30 | Araq | gradha: cool :-) |
| 15:53:43 | gradha | that's for the objc version, however, nimrod generates the following line in the final objc code |
| 15:53:44 | gradha | N_NIMCALL(NSString*, OBJC_LIT)(NCSTRING s); |
| 15:53:49 | gradha | which doesn't make much sense |
| 15:54:13 | gradha | I guess it's doing an internal prototype definition of the proc declared in another module |
| 15:54:32 | Araq | add 'nodecl' to the 'importc' |
| 15:54:51 | Araq | (thought it was obvious :P ) |
| 15:55:43 | gradha | ok, works now, but I have to {.emit.} the #define everywhere I'm going to use it, right? |
| 15:58:13 | gradha | I would need something like the contrary of nodecl to have the #define appear in all the generated code by nimrod which tried to call the objcLiteral proc |
| 15:59:03 | Araq | gradha: patch nimbase.h instead |
| 16:00:43 | Araq | and instead of 'objcLiteral' you can use proc `@` ... :DD |
| 16:01:01 | gradha | yeah, I was going to do that after it was obvious what I meant |
| 16:01:06 | Araq | var x = @"objc string literal" # should work then |
| 16:01:13 | gradha | just like the sql from db_sqlite |
| 16:06:06 | Araq | apriori_: the compiler really dislikes your 'array' solution as it's a structural type |
| 16:06:13 | Araq | and you want a nominal type |
| 16:06:24 | Araq | I really think the wrapper object is a good idea |
| 16:12:33 | dom96 | hello |
| 16:13:47 | gradha | still alive? |
| 16:13:55 | Araq | hi dom96 |
| 16:14:07 | dom96 | gradha: barely. |
| 16:14:45 | * | dom96 wonders if he should try to finish his game for the LD Jam |
| 16:22:26 | apriori_ | Araq: the test case also fails if you replace the array by a simple int |
| 16:22:38 | apriori_ | Araq: so I think its really about the partial specialisation |
| 16:23:10 | Araq | sure, just sayin' |
| 16:23:30 | Araq | we have no partial specialisation in overloading resolution :P |
| 16:23:40 | apriori_ | too bad :P |
| 16:24:45 | Araq | it's suprising how far you get without it though :P |
| 17:03:59 | apriori_ | yeah, well.. I for sure gonna need it for all the generic matrix algos :/ |
| 17:05:56 | Araq | well you need to decide whether you want to stress test the compiler or implement a useful library :P |
| 17:06:17 | Araq | and whether it's about 4x4 matrixes or about big matrixes |
| 17:06:28 | Araq | generic code doesn't cut it |
| 17:06:35 | apriori_ | usefullness is decided by api design, which is decided by working advanced features :P |
| 17:06:58 | apriori_ | you for sure dont wanna specialise the code for every size and value type combo |
| 17:07:24 | Araq | that's true |
| 17:07:38 | Araq | but Gaussian elimination requires efficient row swapping for instance |
| 17:07:40 | apriori_ | anyway.. gotta go now.. need to go to a super market |
| 17:07:55 | apriori_ | bbl |
| 17:07:59 | Araq | bye |
| 17:08:01 | * | apriori_ quit (Quit: Konversation terminated!) |
| 17:47:14 | gour | what is the status of 'func may become a keyword and syntactic sugar for a proc with no side effects' ? |
| 17:53:11 | Araq | pretty much a dead idea |
| 17:53:39 | gour | huh...why |
| 17:53:50 | Araq | 'noSideEffect' is not that restrictive and we have a more elaborate effect system now |
| 17:53:51 | gour | you don't like nosideeffects? |
| 17:54:14 | gour | so, it's possible to achieve the same thing in another way? |
| 17:54:44 | Araq | yes, that already exists: proc p() {.noSideEffect.} |
| 17:56:16 | Araq | and the list of effects can now be more fine-grained |
| 18:04:24 | * | gradha quit (Ping timeout: 256 seconds) |
| 18:26:22 | gour | great |
| 19:18:37 | reactormonk | Araq, maybe move the code to math.nim? |
| 19:18:39 | * | gradha joined #nimrod |
| 19:18:44 | gradha | Araq: moved to elif for https://github.com/Araq/Nimrod/pull/276 |
| 19:19:39 | Araq | reactormonk: that doesn't work either |
| 19:19:48 | reactormonk | Araq, fine |
| 19:20:30 | Araq | gradha: shouldn't it be: (libc.so.6|libiconv.so|libiconv.dylib) for mac os x? |
| 19:20:36 | * | FreeArtMan joined #nimrod |
| 19:20:58 | Araq | I think it's often the lib*.so on mac |
| 19:21:11 | gradha | really? I have no idea |
| 19:21:49 | Araq | well I thought so because it's bsd based |
| 19:22:10 | gradha | doesn't hurt to put all of them |
| 19:22:12 | Araq | but stack overflow says it's libiconv.2.dylib |
| 19:22:44 | gradha | I have /usr/lib/libiconv.2.4.0.dylib |
| 19:22:50 | gradha | then /usr/lib/libiconv.2.dylib |
| 19:22:55 | gradha | and the generic /usr/lib/libiconv.dylib |
| 19:23:03 | Araq | alright |
| 19:23:23 | gradha | what does libiconv.dylib do on linux? |
| 19:23:36 | Araq | it will simply fail to load that |
| 19:23:54 | Araq | but slightly increase the code size ;-) |
| 19:24:08 | gradha | terrible |
| 19:24:28 | Araq | indeed |
| 19:24:39 | gradha | well, on ppc macosx you might need other names for libiconv, but first you need to find ppc macosx nimrod users |
| 19:25:25 | Araq | in retrospect ... using dlsym as the primary import mechanism was not the best idea :P |
| 19:25:43 | dom96 | there used to be one person that used a ppc mac IIRC |
| 19:25:52 | Araq | except for all the other solutions :P |
| 19:26:15 | gradha | my mother has a ppc, I could try nimrod on it these xmas |
| 19:26:31 | Araq | ppc macs are dead anyway |
| 19:26:39 | Araq | better spend the resources on something else |
| 19:26:50 | gradha | eating! |
| 19:27:09 | Araq | DOS support! |
| 19:27:20 | dom96 | RISC OS support! |
| 19:31:07 | gradha | so what is keeping us away from DOS support? Any open github issues? |
| 19:31:34 | Araq | nobody has DOS lying around |
| 19:31:52 | Araq | plus we have some filenames longer than 8 chars now |
| 19:33:15 | dom96 | I for one think this is a serious issue that must be addressed as soon as possible. |
| 19:34:17 | Araq | checking if my haiku port works looks like more fun ;-) |
| 19:34:34 | dom96 | indeed |
| 19:34:41 | Araq | but my haiku vm can't access my harddisc nor the internet |
| 19:35:17 | gradha | is that a limitation of haiku or the vm? |
| 19:37:11 | Araq | the vm I think |
| 19:38:21 | Araq | I'm quite sure the haiku guys do know about the internet |
| 19:42:33 | dom96 | Are you using Virtual Box? |
| 19:42:50 | Araq | yes |
| 19:43:03 | dom96 | Might need to enable internet in your VMs properties |
| 19:44:22 | Araq | but I have |
| 19:46:15 | dom96 | Dunno then |
| 19:46:45 | * | FreeArtMan quit (Ping timeout: 265 seconds) |
| 19:48:48 | Araq | btw gradha |
| 19:49:06 | gradha | yep |
| 19:49:14 | Araq | #278 was not what I had in mind :P |
| 19:49:40 | Araq | I thought about adding a flag to 'load' that determines if missing keys should be an error |
| 19:51:02 | gradha | different people want different things all the time |
| 19:52:20 | gradha | with that flag you would be aiming for something more serious like google protocol buffers and similar systems, right? |
| 19:52:40 | Araq | lol |
| 19:52:57 | Araq | that would be a different module ... |
| 19:53:19 | gradha | yeah, I mean, saying "this has to match all fields" and rigid stuff like that |
| 19:53:26 | gradha | doesn't xml solve that? the rigidness... |
| 19:53:43 | Araq | can't think of anything that xml "solved" :P |
| 19:54:34 | Araq | "The essence of XML is this: the problem it solves is not hard, and it does not solve the problem well." |
| 19:54:58 | gradha | I thought it was more like "XML is like violence, when it doesn't solve the issue, add more" |
| 19:56:23 | gradha | anyway, what you suggest is nice, but I would still separate serialization from validation |
| 19:56:36 | gradha | even if the json loads, it doesn't mean its values are right/trustworthy |
| 19:57:53 | Araq | but for forwards/backwards compatibility we need: ignoreMissingKey and ignoreAdditionalKey |
| 19:58:21 | Araq | and marshal.nim should support that, it's pretty easy to do |
| 19:58:39 | * | FreeArtMan joined #nimrod |
| 19:58:49 | Araq | once you got the object out of marshal.nim you can still validate your invariants |
| 19:58:57 | Araq | that's not part of marshal.nim |
| 20:06:10 | * | Trixar_za is now known as Trix[a]r_za |
| 20:08:44 | * | Vladar joined #nimrod |
| 20:45:54 | * | FreeArtMan quit (Read error: Operation timed out) |
| 21:02:21 | * | gour quit (Quit: WeeChat 0.3.8) |
| 21:26:15 | * | Vladar quit (Quit: Leaving) |
| 22:37:36 | gradha | ahaha, friendly reminder |
| 22:37:50 | Araq | what? |
| 22:38:07 | dom96 | haha |
| 22:38:16 | gradha | just got the email from github about linguist |
| 22:38:23 | dom96 | Araq: What I just posted on the linguist issue :P |
| 22:38:25 | Araq | ah yeah |
| 22:38:45 | dom96 | Next it will be "Moderately hostile reminder" |
| 22:38:46 | Araq | I don't check my email that often anymore now that I get so many bug reports :P |
| 22:41:26 | gradha | I filter all github mails to an IMAP folder so it doesn't get annoying with mailbox clutter |
| 22:41:57 | Araq | that would require to use a proper email client ;-) |
| 22:43:11 | gradha | it's done at the server, so even the crappy mac email client works fine |
| 22:43:37 | gradha | in fact, I have to explicitly click on the imap folder for the email client to show the count properly... |
| 22:44:51 | gradha | pff, so many years and we still have not proper email, no wonder people flock to social networks |
| 22:45:43 | Araq | yeah they use social networks because they were dissatisfied with their email clients ... XD |
| 22:46:21 | Araq | and I thought it's because most people are stupid :P |
| 22:47:01 | Araq | though pretty much by definition they're in fact mediocre ... |
| 22:47:01 | gradha | the amount of people I know who use facebook instead of email is rather large, and sad |
| 22:49:03 | gradha | ok, there you have it http://dl.dropbox.com/u/145894/t/nimtodo.mp4, https://github.com/Araq/Nimrod/pull/288 |
| 22:49:04 | dom96 | well to be fair, it's more natural. i.e. you type in a name, you get the picture of your friend immediately allowing you to confirm visually that you are talking to the right person. |
| 22:49:16 | dom96 | Instead of having to remember silly email addresses :P |
| 22:49:41 | gradha | oh yeah, changing email address is like a nightmare for some people |
| 22:50:25 | dom96 | gradha: omg, that is awesome. |
| 22:51:01 | gradha | thanks, even though it looks crap |
| 22:51:22 | dom96 | what!? It looks amazing. |
| 22:51:36 | Araq | my browser doesn't like mp4 :P |
| 22:51:45 | gradha | well, the UI is just the basic "here's what you get for nothing" look |
| 22:51:46 | dom96 | Araq: Download it and watch it in vlc or w/e |
| 22:52:04 | gradha | Araq: oh man, and here we were talking about people using facebook to email |
| 22:52:42 | gradha | what is really nice is that I didn't have to do a single change to the backend |
| 22:52:57 | gradha | which of course shows off as a brain damaged logic state global variable, but eh, it works |
| 22:53:23 | Araq | I don't mind global variables |
| 22:53:31 | Araq | they are often the lesser evil |
| 22:53:31 | dom96 | how do you store the data on the iPhone? |
| 22:53:39 | dom96 | are you still able to use sqlite? |
| 22:53:43 | gradha | the backend uses sqlite, so that |
| 22:53:48 | gradha | android should too |
| 22:54:02 | gradha | on android you have fancier sqlite-like database for sharing between apps |
| 22:54:07 | gradha | and on ios you have coredata for icloud sync |
| 22:54:17 | gradha | but both require non-sqlite interfaces |
| 22:54:28 | gradha | so it's not easy to do anything portable |
| 22:55:26 | gradha | in theory you could write a full featured storage layer for both if you restrict yourself to an orm interface |
| 22:56:22 | gradha | yuck, those checkboxes are so annoying, I've used unicode chars and they look different on each damn iOS version |
| 22:56:29 | Araq | gradha: do we really need all these .png in repository of the nimrod *compiler* ? |
| 22:56:29 | gradha | should have used a png |
| 22:57:07 | gradha | I don't mind storing this in a separate github project if you prefer, I can understand examples could grow unbounded then |
| 22:57:19 | Araq | indeed |
| 22:57:46 | Araq | the example is good enough as it is, just add a link to the up to date fancy feature rich example |
| 22:58:02 | gradha | ok, I'll close the pull request with a link to the project when I do |
| 22:58:09 | Araq | excellent |
| 22:58:23 | Araq | and register the example on babel please |
| 22:58:34 | dom96 | hrm, looks like it still uses a lot of Obj C code still though, I guess Nimrod can't replace everything? |
| 22:58:35 | gradha | good idea |
| 22:58:58 | gradha | well, you *could* try to write everything in nimrod, but it's not my style |
| 22:59:09 | dom96 | i see |
| 22:59:15 | gradha | when I implement the android version I want to go full java/xml |
| 22:59:18 | gradha | for maximum PAIN |
| 22:59:30 | gradha | otherwise, where's the fun? |
| 22:59:52 | gradha | but yes, a nice abstraction could be provided to write full nimrod apps, at least on android |
| 23:00:16 | gradha | IIRC it's from android 2.2 where you can build full c++ apps without java |
| 23:01:24 | gradha | the NDK provides some hooks into the typical life cycle and you can implement those, previous to that you are forced to write a java app which calls C++ through JNI |
| 23:02:00 | gradha | I guess nobody uses android 1.5 any more, so the full NDK would be fine |
| 23:02:37 | fowl | i wrote an alternate syntax for c++ |
| 23:03:27 | fowl | https://github.com/fowlmouth/cpptranny |
| 23:03:55 | gradha | excellent name |
| 23:04:58 | fowl | lol |
| 23:05:18 | Araq | fowl: cool stuff ;-) |
| 23:05:21 | gradha | wait, doesn't their proposal make C++ not C++? |
| 23:07:11 | gradha | nice quotes "Most significantly we have rejected the "failed experiment" of the C declaration notation, in favour of a more Pascal-like approach." |
| 23:07:40 | fowl | gradha: its still c++, just readable c++ |
| 23:08:27 | gradha | won't compiler people drag their feet to support it? |
| 23:09:00 | gradha | I still remember so many projects restricting themselves to a c++ subset due to compiler support it was not funny |
| 23:09:08 | dom96 | gradha: You might have to hold off with adding this to babel, as currently only libraries are supported, and as far as I can see this is technically an app :P |
| 23:09:23 | gradha | dom96: sure |
| 23:09:50 | fowl | gradha: cpptranny outputs c++, no compiler needs to be changed |
| 23:12:48 | gradha | I wonder if undestanding specs template instantiation error messages from the compiler is going to be funnier than just with plain c++ |
| 23:13:15 | Araq | fowl: argh, why did you write it in ruby? :-( |
| 23:16:54 | * | gradha quit (Quit: gradha) |
| 23:17:15 | fowl | Araq: because i failed at writing a nice parsing dsl |
| 23:17:23 | fowl | im going to take another stab at it though |
| 23:19:08 | Araq | yes please |
| 23:19:25 | Araq | it would be a killer application of nimrod's macros |
| 23:21:36 | * | XAMPP quit (Ping timeout: 272 seconds) |
| 23:23:13 | fowl | i dunno if id use macros for it |
| 23:23:26 | fowl | i think closures would be better |
| 23:24:05 | Araq | *shrug* macros would be faster ;-) |
| 23:24:25 | Araq | grammar: |
| 23:24:42 | Araq | rule "x <- a | b": ... |
| 23:26:16 | fowl | you saw my first attempt right? |
| 23:26:53 | Araq | nope |
| 23:28:39 | fowl | https://gist.github.com/3851985 |
| 23:29:32 | Araq | well? what's wrong with it? |
| 23:29:52 | dom96 | oh dear, the pygments lexer chokes on that |
| 23:30:31 | Araq | yeah that too |
| 23:31:10 | * | dom96 makes a pygmentslexerbugs folder |
| 23:31:10 | fowl | Araq: the design is flawed |
| 23:31:28 | Araq | why? |
| 23:32:38 | fowl | pparserexpr and prule should be merged |
| 23:33:14 | Araq | maybe |
| 23:33:34 | Araq | the bigger issue is that you use a simple loop that tries all possibilities ;-) |
| 23:34:05 | fowl | yea im not proud of that either >_> |
| 23:34:06 | Araq | you should implement some parser generator algorithm like LL(1) |
| 23:34:19 | fowl | nooo do not want something that generates code |
| 23:38:27 | Araq | macros generate code ... :P |
| 23:38:56 | Araq | but yeah just build on Nimrod's PEGs instead |
| 23:39:17 | Araq | which really don't support parsers for now |
| 23:39:59 | Araq | as you can only validate data with them, not build parse trees |