| 00:00:09 | gradha | Araq: it's difficult to evaluate now how much is that a problem of the API or the lack of its documentation |
| 00:00:50 | Araq | well it's inherent problem that you know the concrete syntax and then we have some mapping to some AST and some API |
| 00:01:16 | Araq | that's the advantage of Lisp |
| 00:01:58 | gradha | or its disadvantage |
| 00:02:02 | Araq | but *shrug* I knew that when I created nimrod |
| 00:02:46 | * | io2 quit () |
| 00:02:48 | zahary1 | I should have my alternative grammar in few months |
| 00:03:48 | gradha | zahary1: you are late, it's 2013 the year of nimrod |
| 00:04:02 | * | zahary1 left #nimrod (#nimrod) |
| 00:04:09 | * | zahary1 joined #nimrod |
| 00:05:17 | gradha | zahary1: but then 2014 is the year of Aporia, so you can bring that grammer with a special aporia fork |
| 00:05:42 | Araq | well my talk is out in 2014 |
| 00:05:49 | Araq | and so is my drdobbs article |
| 00:05:58 | Araq | so 2014 will be the year of nimrod |
| 00:06:40 | zahary1 | I'll just assume that 2010s will be the decade of Nimrod and I'll be safe |
| 00:07:44 | gradha | 2015 will be then the year of the nimrod book |
| 00:07:50 | gradha | and 2016 the year of nimrod, the movie |
| 00:08:50 | * | zahary1 left #nimrod (#nimrod) |
| 00:09:00 | * | zahary1 joined #nimrod |
| 00:10:08 | Araq | zahary1: well I still think "undo" in misguided if it doesn't even work for getID |
| 00:10:30 | Araq | what about a somewhat more declarative approach? |
| 00:11:33 | Araq | like a builtin getID(typedesc|expr, dependency: FromModule|FromPhaseOfMoon): int ? |
| 00:12:46 | * | brson joined #nimrod |
| 00:12:53 | zahary1 | well, obviously things like getID will ultimately become a library solutions - for the user it won't be different if he |
| 00:13:01 | zahary1 | if he is using a built-in or a library |
| 00:13:21 | Araq | sure but getID is a very common use case |
| 00:13:21 | zahary1 | but the undo approach is extensible with new types, while built-ins are not |
| 00:13:55 | Araq | well it's not sound, so ... sure it's extensible :P |
| 00:14:25 | Araq | but we don't need new types, we need counters and tables |
| 00:14:28 | zahary1 | and in practice I think there are several ways to assign IDs (I already mentioned two of them with subways like alphabetic/chronological/by size/etc) |
| 00:15:06 | zahary1 | why do you insist so strongly that it's not sound? with sets it's as sounds as it gets |
| 00:16:03 | Araq | no it's inherently unsound because undo is an open problem in computing and the solutions don't undo but instead store a full history to go back in time |
| 00:17:05 | zahary1 | sure, general undo is an open-problem, but isolated undo is solved in every editing program |
| 00:17:44 | Araq | yes. the solution uses a full history. |
| 00:18:15 | zahary1 | well, do you imagine that shared variables will get so much modifications that this will become unpractical? |
| 00:19:11 | zahary1 | they are tool that should be used with care. and you still haven't proposed any workable alternative |
| 00:19:49 | * | brson quit (Ping timeout: 272 seconds) |
| 00:23:03 | Araq | well your use cases look insane for me |
| 00:24:13 | Araq | I'd rather have that explicit mapping somewhere than some fragile build process and we haven't explored further possibilties to decentralize this mapping |
| 00:26:29 | Araq | for instance you could go with a compromise where you give each subsystem some explicit build number and within a subsystem the IDs are generated |
| 00:26:36 | zahary1 | define "insane". as I've said, I've already used similar methods in C++. what you call fragile build process generally consists of no more than a page of code and people are much more likely to forget to add something to a list than a computer |
| 00:26:39 | gradha | Araq: how can you undo without history? the pattern I know is you have a history of undo nodes, and each undoes the previous change |
| 00:28:38 | zahary1 | we used decentralized manually maintained lists initially - you could do this will C++ macros |
| 00:28:39 | zahary1 | #define FOO_MESSAGES(_) \ |
| 00:28:39 | zahary1 | _(BAR) \ |
| 00:28:39 | zahary1 | _(BAZ) |
| 00:28:39 | zahary1 | #define ALL_MESSAGES \ |
| 00:28:39 | zahary1 | FOO_MESSAGES \ |
| 00:28:40 | zahary1 | ANOTHER_MESSAGES |
| 00:28:40 | BitPuffin | dom96: pong |
| 00:29:03 | zahary1 | people complained so the automatic solution was developed |
| 00:29:36 | Araq | gradha: well instead of "undo nodes" you can try to keep the mutating operations in a list then then apply the "opposite" mutating op |
| 00:29:52 | Araq | so inc becomes dec, incl becomes excl etc. |
| 00:30:00 | gradha | Araq: errr.. isn't that what I've described? I've implemented undos like that, for a 3d editor |
| 00:30:13 | gradha | I also believe vim uses such undo |
| 00:31:00 | Araq | editor: "make this rectangle black" |
| 00:31:04 | gradha | if you mean programmers are lazy and store a snapshot of the current document, well, that's inevitable |
| 00:31:04 | Araq | editor: "undo" |
| 00:31:32 | Araq | to undo my example you need to store what the rectangle originally contained |
| 00:31:44 | Araq | you can't "undo" the black op |
| 00:31:53 | Araq | as there is no "undo" |
| 00:32:19 | Araq | a proper "undo" would be to paint it white, if you get what I mean |
| 00:32:35 | zahary1 | and Araq, if you are skeptical of generative programming, why build nimrod in the first place? |
| 00:32:55 | Araq | now that's your argument for everything, zahary1 :P |
| 00:33:13 | gradha | Araq: sorry, I don't see a difference between draing a black rectangle and drawing a "previously saved brush", the first case is of a very boring brush |
| 00:33:51 | gradha | Araq: you could argue that better with filters, but then, aren't all destructive oparations impossible to undo by your definition? |
| 00:34:09 | gradha | like, how to revert a gaussian blur when the information is lost |
| 00:34:30 | Araq | the argument that keeps pushing the complexity to levels that make me depressed |
| 00:36:47 | Araq | gradha: well yes |
| 00:36:58 | zahary1 | well, I like generative programming and that's the main reason I'm building nimrod - I believe that it will enable libraries that are more optimal and easy to use than anything out there - these libraries will be written by experts, but will be easy to use by everyone |
| 00:36:59 | Araq | what's your question again? |
| 00:37:38 | gradha | I don't understand the term "full history" compared to "partial history"? |
| 00:38:54 | gradha | or what exactly is the alternative to "full history" undoes |
| 00:39:21 | gradha | by full I understood you keep all undo operations, while partial you keep only the last few to avoid running out of ram |
| 00:39:56 | gradha | good night, honey badgers |
| 00:40:01 | * | gradha quit (Quit: bbl, need to watch http://www.youtube.com/watch?v=dEf4PJZXBxA again) |
| 00:46:17 | dom96 | BitPuffin: sup |
| 00:46:26 | BitPuffin | dom96: thinking about my code |
| 00:46:38 | BitPuffin | I am refactoring my code |
| 00:46:42 | BitPuffin | but now I'm thinking |
| 00:46:58 | BitPuffin | maybe I should make the shared code a private babel package |
| 00:47:03 | BitPuffin | but that seems like ze painz |
| 00:47:11 | dom96 | is this your game? |
| 00:47:30 | BitPuffin | dom96: no website |
| 00:47:36 | BitPuffin | (s= |
| 00:47:37 | BitPuffin | ) |
| 00:47:39 | BitPuffin | * |
| 00:47:48 | dom96 | then it should be easy |
| 00:47:52 | BitPuffin | basically I am splitting up some code into reusable modules |
| 00:48:04 | dom96 | you can specify a url now |
| 00:48:18 | BitPuffin | like user signup, group functionality, blog etc |
| 00:48:32 | BitPuffin | and then I write glue code and views around that |
| 00:48:36 | BitPuffin | for my personal stuff |
| 00:48:47 | BitPuffin | because fuck no am I gonna make it usable enough for everybody else |
| 00:48:55 | BitPuffin | anyhow |
| 00:49:05 | dom96 | heh |
| 00:49:07 | BitPuffin | making it a babel package feels like it might be overkill |
| 00:49:19 | BitPuffin | however I could do some cool stuff with it I guess |
| 00:49:47 | BitPuffin | Like saying that the blog and group functionality depends on the user functionality |
| 00:49:56 | BitPuffin | but it seems like a pain to maintain that many babel packages lol |
| 00:50:44 | BitPuffin | and in the end, since babel is not used as a build system and doesn't provide the nake like functionality I can't use it to say I wanna run this app now and it would automatically install deps or something |
| 00:51:01 | BitPuffin | I guess babel build would work |
| 00:51:16 | BitPuffin | hmm |
| 00:52:05 | dom96 | Does sound like a bit of an overkill heh |
| 00:52:23 | BitPuffin | yeah for this small stuff indeed |
| 00:52:34 | BitPuffin | however it does otherwise impose a problem |
| 00:52:41 | BitPuffin | say I have |
| 00:52:48 | BitPuffin | app/, app2/, shared/ |
| 00:52:54 | BitPuffin | in app/app.nim |
| 00:53:02 | BitPuffin | I would somehow need to import stuff in shared |
| 00:53:12 | BitPuffin | so I would have to add a funky path thing shit |
| 00:53:23 | BitPuffin | knowatI'msayin? |
| 00:55:01 | BitPuffin | guess it's not horrible |
| 00:55:06 | BitPuffin | but feels tacky |
| 00:55:39 | dom96 | not really |
| 00:55:42 | fowl | no |
| 00:56:05 | fowl | modules in private/ can import private/othermodules fine |
| 00:56:46 | BitPuffin | fowl: well yeah but I didn't mean babel with last example |
| 00:57:04 | dom96 | yes, but they should import it with a fully qualified path: pkgname/private/modulename |
| 00:57:54 | BitPuffin | dom96: well if app/app.nim is compiled in app/ then you would basically have to specify the full path on the system |
| 00:57:56 | BitPuffin | so yay |
| 00:58:03 | BitPuffin | because nimrod hates relative imports |
| 00:58:17 | BitPuffin | anyways I'll just put an app.nimrod.cfg in app/ |
| 00:58:31 | BitPuffin | which adds ../components to das pas |
| 00:58:48 | dom96 | You would need to be a bit more specific about what you want to do. |
| 00:58:58 | BitPuffin | I am quite specific |
| 00:59:14 | dom96 | well then i'm probably just too tired |
| 00:59:42 | BitPuffin | yep |
| 00:59:50 | BitPuffin | and you won't come up with a different solution |
| 00:59:55 | BitPuffin | pretty sure these are the ones |
| 01:01:40 | dom96 | hrm. indeed. fowl suggested what I would suggest. |
| 01:03:08 | BitPuffin | what fowl said doesn't even make sense with what I said |
| 01:03:54 | dom96 | you would put stuff in shared in pkgname/private/shared and then in app.nim import pkgname/private/shared/blah |
| 01:04:31 | BitPuffin | and app.nim would be where? |
| 01:04:47 | dom96 | anywhere in pkgname/ |
| 01:05:07 | dom96 | depending on whether you want to expose it or not |
| 01:05:07 | BitPuffin | but this requires babel right |
| 01:05:15 | dom96 | yes |
| 01:05:28 | BitPuffin | which I am not doing |
| 01:07:10 | fowl | are you sure that app/ app2/ shared/ setup doesnt work? |
| 01:07:19 | fowl | ie did you try it |
| 01:08:27 | BitPuffin | fowl: I currently am |
| 01:08:32 | BitPuffin | fowl: and of course it works |
| 01:08:40 | BitPuffin | just that it feels funny to add ../shared tot he path in app |
| 01:08:43 | BitPuffin | ar app2 |
| 01:09:14 | EXetoC | aren't they in the same dir? if so, add the root dir |
| 01:09:53 | BitPuffin | no app and app2 have their main files in their respective directory |
| 01:10:09 | BitPuffin | but they use code from shared (or actually "components") which is in the parant dir |
| 01:12:32 | EXetoC | I don't see anything wrong with adding paths |
| 01:13:13 | EXetoC | but can't you import relatively like so: import "../bla"? |
| 01:14:01 | EXetoC | undocumented feature I think |
| 01:14:07 | BitPuffin | ugh |
| 01:14:23 | BitPuffin | how is things in components gonna be able to import each other now |
| 01:14:42 | BitPuffin | or wait |
| 01:14:45 | BitPuffin | I guess it would work |
| 01:14:53 | EXetoC | shared/...? |
| 01:15:07 | BitPuffin | shh |
| 01:15:20 | EXetoC | löl |
| 01:18:33 | EXetoC | unrelated pro tip: import="src/common" |
| 01:20:13 | * | DAddYE_ quit (Remote host closed the connection) |
| 01:20:48 | * | DAddYE joined #nimrod |
| 01:20:59 | BitPuffin | EXetoC: w00t |
| 01:22:20 | EXetoC | BitPuffin: automatic import for all project modules (--import) |
| 01:23:27 | BitPuffin | EXetoC: project? |
| 01:23:35 | BitPuffin | it's a cool tip |
| 01:23:40 | BitPuffin | not related though like you said |
| 01:23:57 | BitPuffin | albeit dumb to use |
| 01:24:12 | BitPuffin | because who's gonna look in the .cfg file for a global import |
| 01:25:00 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 01:30:32 | BitPuffin | god damn it |
| 01:31:00 | BitPuffin | I had some kind of a revelation on what I should put where and that it would be nice to follow it strictly but because it is late I completely forgot what it was |
| 01:31:01 | BitPuffin | grr |
| 01:31:04 | EXetoC | people who know about configs maybe. I don't mind having a single implicit import |
| 01:31:17 | BitPuffin | EXetoC: well meh |
| 01:32:02 | BitPuffin | I think this might be a sign that it is time to sleep |
| 01:32:04 | BitPuffin | goodnight guys |
| 01:35:20 | EXetoC | bye |
| 01:36:57 | BitPuffin | last thing, dom96 my ts client is yelling at me to tell you that you need to update the ts server |
| 01:37:08 | BitPuffin | good opportunity to switch to mumble wait wait |
| 01:37:09 | BitPuffin | night! |
| 01:37:11 | BitPuffin | cheers! |
| 01:37:29 | dom96 | nevar |
| 02:09:56 | * | q66 quit (Ping timeout: 246 seconds) |
| 02:20:09 | Varriount_ | Meep |
| 02:20:13 | * | Varriount_ is now known as Varriount |
| 02:20:23 | OrionPKM | hola variount |
| 02:20:47 | Varriount | Hey OrionPKM. |
| 02:32:32 | Varriount | OrionPKM, find a good way to get the project name? |
| 02:32:48 | OrionPKM | not a *good* way, but a way that appears to work. |
| 02:32:58 | OrionPKM | a menu option in the side-bar would be nice though |
| 02:33:15 | Varriount | Huh? |
| 02:33:17 | OrionPKM | now you have to go thru quick commands, "set project file" |
| 02:33:31 | OrionPKM | it parses & serializes the project file |
| 02:41:13 | OrionPKM | how is the scope stuff |
| 02:43:48 | Varriount | Haven't gotten much done. I'm wondering how I'm going to capture the body. |
| 02:45:04 | OrionPKM | hmm. capturing the parameters should be easy enough |
| 02:45:08 | OrionPKM | right? |
| 02:45:17 | Varriount | Yeah, but the body, not so much |
| 02:46:00 | OrionPKM | what do you want to do that fur |
| 02:46:25 | Varriount | To give the body a scope? |
| 02:48:33 | Varriount | OrionPKM, what about the method used in that github repo you showed me? |
| 02:48:49 | OrionPKM | thats what i used |
| 02:48:55 | Varriount | Ah |
| 02:49:19 | OrionPKM | it'd be nice just to be able to use @ to look up proc |
| 02:49:48 | Varriount | Huh? |
| 02:49:58 | OrionPKM | look up *on* procs |
| 02:51:27 | OrionPKM | ctrl+r |
| 02:53:20 | Varriount | OrionPKM, and what do you need for that to work? |
| 02:53:37 | OrionPKM | no idea |
| 02:53:46 | OrionPKM | figured you would know |
| 02:53:52 | OrionPKM | scopes? :P |
| 02:54:08 | Varriount | Maybe? |
| 02:57:43 | * | OrionPK joined #nimrod |
| 03:00:48 | * | DAddYE joined #nimrod |
| 03:04:35 | * | OrionPK quit (Read error: Connection reset by peer) |
| 03:23:08 | gcr | Is there a nice way to have a pragma that passes -lm to the compiler without any special flags to "nimrod c" ? |
| 03:23:49 | gcr | I have a self-contained .c file that I need to include into my source, so I'm saying {.compile: "noise.c".}, then defining all of its functions with {.importc.}, but it needs libm |
| 03:25:45 | Varriount | gcr, I'm looking through the manual. Off the top of my head, I think that's something that would go in the configuration file, or possibly the nake file, for whatever nimrod file you are compiling. |
| 03:26:30 | Varriount | gcr, also, libm? |
| 03:28:26 | Varriount | Ah, here we go. gcr, look at this page, around this section -> http://nimrod-lang.org/nimrodc.html#compile-pragma |
| 03:29:22 | gcr | yeah, -lm for math, floor, sinf, etc |
| 03:29:24 | gcr | hm! |
| 03:29:44 | gcr | i could just ask for {.link: "/usr/lib/libm.a".} |
| 03:30:36 | Varriount | I wouldn't know. A: I run Windows, not linux, and B: I haven't ever needed to specifically specify -l in anything I've compiled in nimrod. |
| 03:31:15 | gcr | ok, thanks for your help |
| 03:31:48 | Varriount | gcr, however, I think your best bet is to use a project configuration file. |
| 03:31:56 | gcr | it's weird because if i compile something that depends on the 'sets' module, -lm is passed in the compiler flags |
| 03:32:01 | gcr | Hm |
| 03:33:12 | gcr | Aha! {.passl: "-lm".} |
| 03:33:17 | gcr | that's from system/math.nim |
| 03:33:19 | Varriount | when defined(Posix) and not defined(haiku): |
| 03:33:19 | Varriount | {.passl: "-lm".} |
| 03:33:28 | Varriount | Oh, :p |
| 03:34:19 | Varriount | gcr, just make sure that you keep windows users in mind. :P |
| 03:34:29 | gcr | true, maybe just "import math" is good enough |
| 03:34:32 | gcr | Thanks, varriount |
| 03:41:47 | OrionPKM | varriount cant you look at the python plugin to figure out how it does the scopes |
| 03:42:03 | Varriount | OrionPKM, I'm doing that right now. :P |
| 03:42:40 | Varriount | I'm actually borrowing and modifying the python scope selectors for nimrod procedures. |
| 03:43:00 | OrionPKM | heh |
| 03:43:05 | OrionPKM | cool |
| 03:48:52 | Varriount | I don't think I'm going to get much done tonight. Not with lack of sleep and loud movies playing two rooms away. |
| 03:49:30 | OrionPKM | two whole rooms? |
| 04:02:47 | * | brson joined #nimrod |
| 04:12:44 | * | OrionPK joined #nimrod |
| 04:13:30 | * | OrionPK quit (Client Quit) |
| 04:14:17 | * | OrionPK joined #nimrod |
| 04:16:07 | * | OrionPK quit (Client Quit) |
| 04:24:34 | * | darkf_ joined #nimrod |
| 04:29:18 | * | darkf quit (Read error: Connection reset by peer) |
| 04:29:21 | * | Icefoz quit (Ping timeout: 240 seconds) |
| 04:29:42 | Varriount | OrionPKM, without doors |
| 04:30:02 | OrionPKM | ah |
| 04:30:19 | Varriount | And in one instance, walls |
| 04:31:07 | Varriount | That is, two rooms don't have a wall dividing them. |
| 04:32:41 | * | Icefoz joined #nimrod |
| 04:43:41 | * | darkf_ is now known as darkf |
| 04:47:41 | * | OrionPKM quit (Remote host closed the connection) |
| 04:51:29 | * | OrionPK joined #nimrod |
| 04:52:00 | OrionPK | ah there we go |
| 04:54:06 | fowl | ahoy |
| 04:56:13 | Varriount | Hey fowl. |
| 05:03:56 | Varriount | Gah. Save me from API designers and their lack of consideration. It's going to be... interesting to see how fsmonitor.nim can be implemented on windows. |
| 05:09:22 | * | xenagi joined #nimrod |
| 05:12:24 | * | brson quit (Quit: leaving) |
| 05:13:30 | fowl | maybe there's a windows library with inotify's api |
| 05:15:07 | Varriount | Possibly, but Araq doesn't want dependancies unless absolutely necessary |
| 06:04:59 | * | Roin quit (Ping timeout: 272 seconds) |
| 06:06:07 | * | gcr quit (Remote host closed the connection) |
| 06:06:15 | * | OrionPK quit (Ping timeout: 272 seconds) |
| 06:07:25 | * | Roin joined #nimrod |
| 06:29:34 | * | xenagi quit (Remote host closed the connection) |
| 06:56:27 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 07:10:04 | * | BitPuffin quit (Ping timeout: 246 seconds) |
| 07:11:53 | * | Varriount quit (Read error: Connection reset by peer) |
| 07:12:20 | * | Varriount joined #nimrod |
| 07:16:22 | * | Roin quit (Ping timeout: 246 seconds) |
| 07:23:50 | * | ics joined #nimrod |
| 07:29:08 | * | Roin joined #nimrod |
| 07:42:41 | * | Roin quit (*.net *.split) |
| 07:45:19 | * | Demos_ quit (Ping timeout: 272 seconds) |
| 07:50:05 | * | Roin joined #nimrod |
| 08:28:28 | * | zielmicha1 quit (Read error: Operation timed out) |
| 08:44:12 | * | zielmicha joined #nimrod |
| 08:52:43 | * | gradha joined #nimrod |
| 09:18:01 | gradha | I'm looking at docgen's initTokRender, which works like the highlite module, is there any way I can parse the code to get an AST similar to a macro? I want to extract the types of proc params without reinventing the wheel |
| 09:23:02 | * | Roin quit (Ping timeout: 240 seconds) |
| 09:23:50 | * | Roin joined #nimrod |
| 09:29:59 | gradha | Error: 'parseExpr' can only be used in compile-time context |
| 09:39:54 | fowl | gradha, because it returns a pnimrodnode |
| 09:45:28 | gradha | maybe I should copy/paste the procs into a nim file and use idetools on them |
| 10:06:08 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 10:12:57 | * | girvo joined #nimrod |
| 10:18:09 | * | girvo quit (Remote host closed the connection) |
| 10:43:55 | * | q66 joined #nimrod |
| 10:52:47 | * | aftershave quit (Quit: Textual IRC Client: www.textualapp.com) |
| 10:53:08 | * | aftershave joined #nimrod |
| 11:05:50 | * | girvo joined #nimrod |
| 11:06:01 | girvo | hey all, happy holidays |
| 11:06:16 | gradha | happy holidays, for those not working |
| 11:10:23 | * | girvo quit (Quit: leaving) |
| 11:21:09 | * | psquid quit (Ping timeout: 248 seconds) |
| 11:54:41 | dom96 | hello |
| 11:54:47 | gradha | hi |
| 12:08:54 | * | zielmicha-cloud quit (Quit: Connection closed for inactivity) |
| 13:07:45 | * | darkf quit (Quit: Leaving) |
| 14:52:54 | * | Icefoz quit (Quit: leaving) |
| 14:53:03 | * | Icefoz joined #nimrod |
| 15:26:59 | * | OrionPK joined #nimrod |
| 15:35:50 | NimBot | Araq/Nimrod devel 09be7ea Araq [+0 ±88 -0]: case consistency part 1 |
| 15:35:50 | NimBot | Araq/Nimrod devel cbe7392 Araq [+0 ±9 -0]: case consistency part 2 |
| 15:47:24 | * | gradha_ joined #nimrod |
| 15:49:43 | * | gradha quit (Ping timeout: 245 seconds) |
| 16:20:36 | * | achim joined #nimrod |
| 16:30:32 | * | achim quit (Quit: Computer has gone to sleep.) |
| 16:39:08 | * | Demos_ joined #nimrod |
| 16:49:11 | * | achim joined #nimrod |
| 17:04:11 | * | achim quit (Quit: Computer has gone to sleep.) |
| 17:17:35 | * | DAddYE quit (Remote host closed the connection) |
| 17:18:02 | * | DAddYE joined #nimrod |
| 17:22:35 | * | DAddYE quit (Ping timeout: 252 seconds) |
| 17:56:21 | * | DAddYE joined #nimrod |
| 18:20:41 | * | zielmicha-cloud joined #nimrod |
| 19:09:25 | OrionPK | is there a way to produce an expression/statement with a macro that can be directly assigned |
| 19:09:41 | OrionPK | i.e. var someField = someMacro() |
| 19:10:43 | gradha_ | yesterday I posted this, seems to be what you want https://gist.github.com/gradha/8140318 |
| 19:15:06 | OrionPK | ahh, just needed to return an expr |
| 19:15:08 | OrionPK | instead of a stmt |
| 19:15:09 | OrionPK | thanks |
| 19:32:37 | * | achim joined #nimrod |
| 19:33:59 | Araq | gradha_: since you know about these things ... do you feel like giving a try to convert my slides to PDF? |
| 19:34:44 | * | ics joined #nimrod |
| 19:35:43 | gradha_ | how am I meant to convert them? |
| 19:35:52 | * | achim quit (Client Quit) |
| 19:36:19 | OrionPK | wkhtml2pdf |
| 19:36:36 | Araq | well I give you source and you can play with it |
| 19:36:37 | gradha_ | OrionPK: did a cat jump over your keyboard? |
| 19:36:44 | gradha_ | Araq: sounds legit |
| 19:37:10 | OrionPK | it's a PDF converter |
| 19:38:10 | gradha_ | I've only made slides once, through asciidoc + slidy, I think yours were in a similar fashion |
| 19:39:55 | * | BitPuffin joined #nimrod |
| 19:40:05 | * | ics quit (Ping timeout: 252 seconds) |
| 19:40:33 | Araq | yup, I used nimrod's rst2html and slidy |
| 19:41:02 | Araq | but I tried latex beamer before |
| 19:41:20 | Araq | decided to never ever use it again :P |
| 19:42:08 | gradha_ | people were complaining about slidy not being mobile, maybe the raw html would be enough for those? you know, without js and stuff |
| 19:44:31 | Araq | raw html means no slides? |
| 19:44:43 | Araq | just a long text? |
| 19:44:48 | * | ics joined #nimrod |
| 19:45:02 | gradha_ | I guess it means splitting into html pages and clicking "next" |
| 19:45:16 | Araq | thinking about it ... |
| 19:45:22 | Araq | I disabled left click |
| 19:45:28 | Araq | XD |
| 19:45:34 | Araq | that could be the cause |
| 19:45:43 | gradha_ | sounds problematic |
| 19:45:50 | Araq | but *shrug* I optimized the presentation for the presentator |
| 19:53:34 | gradha_ | what's wrong with these companies who give us free stuff? bitbucket doesn't allow animated gifs for avatars either |
| 19:54:25 | gradha_ | oh, and they tease me with an animated preview window so I can crop the gif |
| 20:18:19 | gradha_ | Araq: do you have any special trick for https://github.com/Araq/Nimrod/pull/781 to parse parameter types without having to reimplement the compiler? Can't use macros.parseExpr |
| 20:19:26 | Araq | haven't looked yet at your commits, sorrry |
| 20:19:45 | Araq | what's your problem again? parser.parseExpr exists when you're in the compiler |
| 20:20:10 | gradha_ | I want that for docgen at runtime |
| 20:20:25 | gradha_ | so I can feed it a line of proc definition and returns me the ast |
| 20:20:58 | gradha_ | hmm... or maybe move docgen to compile time with FFI |
| 20:22:13 | Araq | what's the problem? |
| 20:22:28 | gradha_ | the problem is I'm lazy |
| 20:22:32 | Araq | that you're in docutils, not in compiler? |
| 20:22:45 | gradha_ | I want to make unique hrefs for documentation |
| 20:22:53 | gradha_ | but you can't because of overloading |
| 20:23:20 | gradha_ | to make that unique, I need to parse parameters/types, so I was hoping parseExpr would give me the ast to avoid myself the pain of parsing |
| 20:23:40 | gradha_ | but docgen can't use parseExpr at runtime |
| 20:23:55 | gradha_ | hmm... maybe I should look up the repl code |
| 20:24:17 | gradha_ | so right now I'm generating numbered links when there's a symbol name collision |
| 20:25:07 | * | brson joined #nimrod |
| 20:26:59 | Araq | why do you remove the "last" pragma? (whatever that is?) |
| 20:27:23 | gradha_ | that's for the toc, when you hover over items, it's not very useful information |
| 20:27:47 | gradha_ | the toc only needs enough info to differentiate type overloads, so I cut everything else |
| 20:30:05 | Araq | well you PR is not acceptable, sorry |
| 20:30:28 | Araq | the good news is that it's all way easier to do |
| 20:33:22 | Araq | for instance, if you don't want to render pragmas, add that to the 'initTokRender' |
| 20:33:44 | gradha_ | I know, I just don't want the last one |
| 20:34:08 | Araq | then add that feature to the token renderer |
| 20:34:55 | Araq | extract the 'while true' loop to a proc and call that twice, once for the header, once for the link |
| 20:35:21 | Araq | or something like that |
| 20:39:35 | Araq | you can also call renderTree on a parameter list |
| 20:39:47 | Araq | no need to re-parse anything |
| 20:40:08 | Araq | n[paramsPos] contains the parameter list if n.kind == nkProcDef etc. |
| 20:40:52 | gradha_ | that's a relief |
| 20:41:05 | gradha_ | bbl |
| 20:59:00 | * | BitPuffin quit (Quit: WeeChat 0.4.2) |
| 21:06:54 | * | brson quit (Quit: leaving) |
| 21:58:04 | * | BitPuffin joined #nimrod |
| 22:40:28 | dom96 | BitPuffin: yo |
| 22:42:07 | * | achim joined #nimrod |
| 22:45:22 | * | achim quit (Client Quit) |
| 22:46:57 | * | psquid joined #nimrod |
| 22:47:06 | * | psquid quit (Changing host) |
| 22:47:06 | * | psquid joined #nimrod |
| 22:49:35 | * | brihat joined #nimrod |
| 22:49:50 | * | brihat left #nimrod (#nimrod) |
| 22:56:43 | * | Demos_ quit (Read error: Connection reset by peer) |
| 23:07:25 | * | darkf joined #nimrod |
| 23:19:00 | gradha_ | good night, honey badgers |
| 23:19:05 | * | gradha_ quit (Quit: bbl, need to watch http://www.youtube.com/watch?v=dEf4PJZXBxA again) |
| 23:25:24 | * | OnionPK joined #nimrod |
| 23:25:50 | * | brihat joined #nimrod |
| 23:25:51 | * | brihat left #nimrod (#nimrod) |
| 23:28:20 | * | fowl quit (Ping timeout: 252 seconds) |
| 23:28:25 | * | fowlmouth joined #nimrod |
| 23:31:23 | * | shodan45 quit (Ping timeout: 245 seconds) |
| 23:33:41 | * | fowlmouth is now known as fowl |
| 23:51:04 | * | Demos joined #nimrod |
| 23:52:16 | Demos | how in the name of god do nimrod's tests work? trying to add tests for my small addition to algorithms |
| 23:56:13 | Araq | well there is tests/tester |
| 23:56:23 | Araq | that runs the excessive test suite |
| 23:56:26 | Demos | so I add a file to test/run |
| 23:56:37 | Demos | like tests/run/tfoo.nim |
| 23:56:44 | Araq | yeah |
| 23:56:58 | Demos | and in it I have a discard block at the top saying what expected output is |
| 23:57:04 | Araq | yeah |
| 23:57:05 | Demos | then I run koch tests |
| 23:57:11 | Demos | and that file does not get compiled |
| 23:57:30 | Araq | well it should |
| 23:57:39 | Araq | but koch tests runs all the tests |
| 23:57:45 | Araq | so it takes a while |
| 23:58:03 | Demos | I did not see an error, does it get its library from lib/... or from the system's nimrod installation |
| 23:58:18 | Araq | you can invoke the tester directly with a single test |
| 23:59:41 | Araq | well it invokes "nimrod" and nimrod gets its stdlib from the $lib variable |
| 23:59:58 | Araq | which is set somewhere in its config system iirc |