00:03:48 | * | ics quit (Ping timeout: 240 seconds) |
00:04:22 | Araq | no it doesn't "really limit" anything |
00:08:19 | * | ics joined #nimrod |
00:25:52 | * | ics quit (Ping timeout: 240 seconds) |
00:26:27 | * | johnsoft quit (Ping timeout: 245 seconds) |
00:28:29 | * | xenagi joined #nimrod |
00:30:58 | flaviu | ? |
00:47:11 | * | boydgreenfield quit (Quit: boydgreenfield) |
01:00:23 | * | brson quit (Quit: leaving) |
01:00:48 | * | brson joined #nimrod |
01:01:33 | * | brson_ joined #nimrod |
01:04:58 | * | Boscop quit (Read error: Connection reset by peer) |
01:05:22 | * | brson quit (Ping timeout: 255 seconds) |
01:05:23 | * | Boscop joined #nimrod |
01:10:58 | adoniscik | how can you make typedesc arguments have a default value? I can't find the right incantation. |
01:11:46 | adoniscik | proc foo(n: int, T : typedesc = bar) : seq[T] = result = newSeq[T](n) |
01:11:54 | adoniscik | what should bar be? |
01:19:01 | flaviu | adoniscik: I don't have a suggestion, but try overloading as a workaround |
01:20:24 | adoniscik | why can every other type have a default value and not typedesc? |
01:22:13 | * | saml_ joined #nimrod |
01:28:17 | * | boydgreenfield joined #nimrod |
01:29:32 | * | brson_ quit (Quit: leaving) |
01:29:47 | * | brson joined #nimrod |
01:33:31 | * | q66 quit (Quit: Leaving) |
01:38:55 | flaviu | I'm not sure, but its probobly something thats been overlooked |
01:39:29 | adoniscik | by us now or the compilers' contributors? |
01:55:20 | flaviu | Not by us, the compiler is the issue here. I'd go as far as to say any unexpected behavior is an issue |
01:55:55 | * | Jesin quit (Ping timeout: 250 seconds) |
01:58:16 | * | Jesin joined #nimrod |
02:08:11 | * | vendethiel quit (Ping timeout: 256 seconds) |
02:08:52 | boydgreenfield | Question for anyone up: What does the compile_only flag do vs. just simply c? |
02:10:54 | boydgreenfield | (I’m trying to figure out cross-compilation, specifically) |
02:19:19 | * | ics joined #nimrod |
02:28:48 | * | ics quit (Ping timeout: 240 seconds) |
02:36:42 | * | boydgreenfield quit (Quit: boydgreenfield) |
02:40:12 | OrionPK | something borked with the nimrod parser? peg"\"{.+}\"" isnt parsing |
02:40:57 | OrionPK | works with peg("\"{.+}\"") |
02:41:28 | flaviu | I'll look into it, sounds easy to fix |
02:44:07 | Demos | adoniscik, nobody really understands how typedescs are supposed to work, I think zah wrote the implementation we have and araq does not understand the subtle semantics |
02:44:25 | Demos | and he has been too busy to polish a specification for them |
02:45:54 | adoniscik | Demos, I can live with an honest answer! I'm just trying to figure out how to make a function return a variable type, and to separate the language's bugs from its features |
02:47:08 | Demos | adoniscik, you can not have a return type determined by control flow |
02:47:12 | Demos | at least not yet |
02:47:21 | Demos | what are you trying to do? |
02:47:30 | adoniscik | proc foo(n: int, T : typedesc = bar) : seq[T] = result = newSeq[T](n) |
02:47:50 | adoniscik | I'm trying to set the default type of T |
02:48:00 | adoniscik | it only works when I specify it explicitly |
02:48:14 | adoniscik | as in foo(10, float) |
02:48:31 | adoniscik | what I really wanted was an array but I couldn't do that |
02:48:55 | Demos | yeah just overload it |
02:49:09 | Demos | although to be honest you should probably just call newSeq directly |
02:49:16 | adoniscik | write a separate proc for each type? no thanks |
02:49:48 | Demos | no, write a proc for the default type proc foo(n: int): seq[T] = result = newSeq[bar](n) and one for all the other types |
02:49:58 | * | ics joined #nimrod |
02:50:00 | flaviu | adoniscik: proc foo(n: int, T...):seq[T]..., and proc foo(n: int): seq[Bar] = ... |
02:50:10 | adoniscik | ah, great |
02:50:16 | adoniscik | or better |
02:50:34 | Demos | or just call newSeq directly and specify the type |
02:51:08 | adoniscik | but this is still a bug, surely; typedesc should accept a default value |
02:51:35 | Demos | well it can not be a bug since typedescs have no realy spec :D |
02:51:39 | Demos | *real |
02:52:36 | adoniscik | then the docs should say that so users don't waste time trying, since it's an obvious application |
02:53:32 | Demos | well it may be that they should allow it. Araq needs to sit down with zah and decide how they are supposed to work |
02:54:48 | Demos | but feel free to submit a pull request on the docs or open an issue about this |
03:01:10 | flaviu | OrionPK: pretending `peg` to the string puts it in raw mode, the escapes have no effect |
03:01:48 | * | brson quit (Ping timeout: 240 seconds) |
03:02:51 | flaviu | so instead of parsing "|\"|f|o|o|", it does "|\|"foo" |
03:13:03 | OrionPK | huh.. |
03:13:04 | OrionPK | ok |
03:13:15 | OrionPK | prepending |
03:13:17 | OrionPK | I guess u mean |
03:18:25 | adoniscik | sorry if I'm bugging everyone with my questions, but I'm still trying to wrap my head around this language. Array types and sizes have to be known at compile time, right? If so, doesn't that rule them out for pretty much any data-related use where you don't know precisely how big the array has to be? |
03:19:21 | flaviu | adoniscik: Yep, pretty much |
03:19:26 | flaviu | Seqs work in those cases |
03:20:48 | adoniscik | and the way to get around it is to use templated arrays? |
03:21:27 | flaviu | No, its to use seqs |
03:21:40 | flaviu | if you're just storing structs, you can use unchecked arrays |
03:22:38 | adoniscik | I'm doing numerical analysis |
03:22:44 | adoniscik | I thought arrays were the fast ones? |
03:23:05 | adoniscik | Plus I need to interface with C libraries, so I thought I needed arrays |
03:23:21 | flaviu | what are you storing in the arrays? |
03:23:31 | adoniscik | just numbers |
03:23:49 | flaviu | Ok, check this out then: http://nimrod-lang.org/manual.html#unchecked-pragma |
03:24:11 | flaviu | its basically just a raw pointer with nicer syntax |
03:27:37 | * | goobles quit (Ping timeout: 246 seconds) |
03:29:37 | * | gsingh93 quit (Quit: Connection closed for inactivity) |
03:30:36 | adoniscik | I suppose it's not possible to convert a seq to an array? |
03:31:56 | flaviu | I don't think so |
03:32:02 | flaviu | but I could be wrong |
03:33:13 | adoniscik | because if I can't I will have a bunch of seqs since I can't generate variable-sized arrays |
03:34:18 | flaviu | Wouldn't unchecked arrays work for your usecase? |
03:34:38 | adoniscik | that means I will have to write procs that assume the data are in seqs, even if the unchecked pragma lets me otherwise use variable-length arrays |
03:35:11 | adoniscik | well let's think: I want to create a data structure of a length which will be determined during run-time |
03:35:18 | adoniscik | that means I have created a seq |
03:35:36 | adoniscik | will a proc with .unchecked. process this seq? |
03:35:49 | adoniscik | remember that the data is currently in a seq |
03:35:57 | adoniscik | not some array of unknown length |
03:36:07 | adoniscik | am I missing the point? |
03:36:26 | flaviu | unchecked is only usable in type declerations |
03:36:38 | adoniscik | I noticed that :( |
03:36:43 | flaviu | it tells the compiler that an array does not have to have its length specified |
03:37:04 | flaviu | That means you can allocate your own memory, of any length |
03:37:12 | flaviu | and use the unchecked array to index into it |
03:37:28 | adoniscik | using new? |
03:37:29 | flaviu | but you need to deal with your own bounds checks |
03:37:42 | flaviu | IDK, but I have some code, let me dig it up |
03:38:08 | adoniscik | this seems so hacking for something so commonplace. |
03:38:11 | adoniscik | hackish |
03:38:51 | adoniscik | thanks, I'd like to see it |
03:39:18 | flaviu | https://gist.github.com/flaviut/344d7635137de87c1f59 |
03:39:48 | flaviu | you can't put refs into there, or you get a memory leak |
03:40:26 | adoniscik | am I supposed to get the feeling we should just stick to seq for everything, including numerical analysis? |
03:40:52 | adoniscik | and another question, if I did use a seq, would I be able to pass it to a C function that wants an array? |
03:41:05 | adoniscik | a C array, that is |
03:42:56 | flaviu | addr might work, but I don't know |
03:43:58 | flaviu | Although you should wait until tomorrow and ask Araq, I don't want to spread wrong information |
03:44:42 | flaviu | adoniscik: re first question: That's the feeling I get, can't say I'm too happy with it. |
03:45:54 | adoniscik | have you guys discussed this? The docs should recommend something because it is not clear what we're supposed to do. |
03:48:06 | flaviu | Well, sort of, responses are mostly "why would you want that", and "just use a seq" |
03:49:14 | adoniscik | okay, so it is the recommended approach. then what good are arrays? How often are you going to know how big it needs to be at compile time? They seem so useless. |
03:50:03 | adoniscik | all the pragma and templating magic tricks notwithstanding |
03:52:06 | flaviu | Arrays are useful sometimes, but beyond a few cases I agree with you |
04:02:35 | * | saml_ quit (Quit: Leaving) |
04:05:46 | * | bjz quit (Read error: Connection reset by peer) |
04:06:46 | * | bjz joined #nimrod |
04:17:41 | * | superfunc joined #nimrod |
04:19:27 | Skrylar | adoniscik, flaviu: an array is useful when you have fixed-size memory requirements |
04:20:28 | Skrylar | Some domains (like software synthesizers for music) perform best when they have fixed performance at all times; so for those, you set hard limits (e.g. "you can have four envelope generators and thats it") in which case an array becomes useful. That way you always know how much space you need, and you can basically never spiral out of control. |
04:21:14 | Skrylar | You also get guarantees that you won't run out of memory at random times, whereas a sequence tends to consume more as-needed and requires you to be able to handle running out randomly |
04:22:35 | * | xenagi quit (Quit: Leaving) |
04:23:41 | * | mwbrown quit (Ping timeout: 250 seconds) |
04:26:09 | flaviu | Is that the normal case? |
04:26:20 | Skrylar | Its the normal case for DSP code. |
04:26:51 | flaviu | DSP code isn't typical, and from what I understand a lot of that gets done with the programmable field gate array things anyway |
04:27:04 | Skrylar | Some heuristics (e.g. the LiveLight project for analyzing and automatically summarizing live video) also made a big deal out of using fixed memory |
04:27:34 | flaviu | I'm just saying to optimize the language for the common case |
04:27:43 | Skrylar | So you mean, compete with java. :P |
04:27:53 | flaviu | Make it easier to have runtime-length arrays |
04:28:00 | Skrylar | Can't |
04:28:10 | flaviu | Look at Java. It must have done something right |
04:28:20 | Skrylar | Nimrod compiles to C. that means the C compiler has to support it. |
04:28:23 | flaviu | Otherwise not everyone and their mother would be using it |
04:28:33 | flaviu | Skrylar: The C compiler supports it |
04:28:34 | Skrylar | And say, Microsoft has made big pushes to get out of having variable length arrays out of the spec |
04:28:48 | flaviu | VLAs are on the stack, I'm not tied to that |
04:28:53 | Skrylar | so what happens if someone turns on C++ mode |
04:29:13 | flaviu | I want https://gist.github.com/flaviut/344d7635137de87c1f59 , but with GC |
04:29:20 | flaviu | That is 100% working |
04:29:22 | Skrylar | (i'm aware that on say, windows, there are stackalloc routines, but i don't know who is presently interested in maintaining it for every platform.) |
04:29:26 | flaviu | or at least 90% working |
04:29:39 | flaviu | I don't care about allocating on the stack, that is fragile |
04:30:04 | Skrylar | thats usually what VLAs are though |
04:30:09 | flaviu | and in the 1% of cases where that is really needed, the programmer can figure out alloc and do it themselves |
04:30:13 | Skrylar | extra space allocated within the function |
04:30:37 | flaviu | I don't want VLAs, although I was playing around with trying to get them once |
04:30:53 | Skrylar | I suspect the reason we don't have every bell and whistle in computer science is because nimrod compiles to C, not Lisp, so there are portability issues :\ |
04:31:06 | Skrylar | Otherwise we'd have full-on continuations :P |
04:31:13 | flaviu | Skrylar: I want a goddamn pointer with a length field |
04:31:26 | flaviu | A bit far away from lisp |
04:32:01 | adoniscik | Skrylar, and in what data structure would you store the actual musical samples? |
04:32:20 | Skrylar | adoniscik: samples are usually stored in an array of integers |
04:32:50 | flaviu | Skrylar: What if you want to configure the buffer from a configuration file :O |
04:32:54 | Skrylar | usually the DAW will allow you to change the size of this buffer, but in that case it pre-allocates the arrays |
04:33:08 | Skrylar | it doesn't grow dynamically |
04:33:21 | adoniscik | but you don't know it at compile time |
04:33:31 | Skrylar | the VST does |
04:33:39 | adoniscik | you allocate it when you read the file or record it |
04:35:58 | adoniscik | right? Suppose the song is in a file and you want to load it. How are you going to use an array? |
04:36:04 | Skrylar | flaviu: nothing stops you from making a struct with a pointer and an int in it? |
04:38:43 | adoniscik | only when you attempt to load the file do you know how big the array needs to be |
04:38:54 | adoniscik | this is so basic I must be missing something |
04:39:13 | Skrylar | adoniscik: usually music software never loads the whole file |
04:39:30 | Skrylar | it reads it in to fixed-size buffers, runs that through a decoder, and plays samples through another fixed-size buffer |
04:39:52 | flaviu | Skrylar: I think he means configuration files |
04:39:59 | adoniscik | no he understood. suppose you want to edit it in your DAW then. |
04:40:06 | Skrylar | flaviu: ok, but setLen(seq, <length>) works for those |
04:41:09 | adoniscik | or in my case, I want to crunch numbers, but obviously I need to be able to accept and generate arrays of variable length |
04:41:12 | Skrylar | It might be nice if araq exposed element count and element capacity separate like rust does, since it already stores both of that information internally |
04:41:18 | Skrylar | you'd just replace setLen with setCapacity |
04:41:41 | Skrylar | I might be able to PR that later |
04:42:45 | flaviu | Skrylar: "<Araq> flaviu: in 2 places but forget it you won't get that feature anytime soon" |
04:42:45 | flaviu | No GC == not as useful |
04:48:02 | adoniscik | when you do an importc, where does nimrod look for the function? I get an undefined reference |
04:48:18 | Skrylar | thats a linker error |
04:48:37 | adoniscik | LD_LIBRARY_PATH then>? |
04:48:38 | Skrylar | importc just tells nimrod how to call a c function |
04:48:53 | adoniscik | from which library? |
04:49:01 | Skrylar | you have to either use the one pragma which tells it which library to link, or add a -wl,-lmylib to the nimrod c call |
04:49:21 | flaviu | If you have a header file in the dir, I think that'll work |
04:50:52 | flaviu | Anyway, I should have been asleep a hour ago, night |
04:54:13 | * | Demos quit (Read error: Connection reset by peer) |
04:55:19 | * | flaviu quit (Ping timeout: 250 seconds) |
04:59:57 | * | boydgreenfield joined #nimrod |
05:06:29 | * | darkfusion quit (Ping timeout: 272 seconds) |
05:35:16 | * | Varriount__ joined #nimrod |
05:38:58 | * | Varriount_ quit (Ping timeout: 264 seconds) |
06:02:59 | * | mko quit (Ping timeout: 264 seconds) |
06:04:01 | * | nande quit (Read error: Connection reset by peer) |
06:08:23 | Araq | seriously guys? again? |
06:08:37 | Araq | adoniscik: use a seq. |
06:08:44 | Araq | flavius: use a seq. |
06:09:08 | adoniscik | when interfacing with C libraries that expect arrays? |
06:09:11 | adoniscik | good morning |
06:09:27 | Araq | passing a seq to a C proc works: cast[ArrayType](addr s[0]) |
06:09:47 | Araq | there have been written books about it |
06:10:00 | Araq | well "books" is a metaphor here |
06:10:22 | Araq | it's always the same thing people ask, how come our tutorial doesn't mention it? |
06:10:43 | adoniscik | you tell me, I didn't write it! |
06:11:10 | Araq | well I don't read our docs |
06:12:10 | Araq | and why flaviu still wants Java like arrays when they have clearly less features but save a single int field is beyond me |
06:12:17 | adoniscik | oh, and do you have anything to say about default values of typedesc args? |
06:12:37 | adoniscik | whether it is supposed to work, because it does not |
06:14:11 | Araq | I can easily make it work but I dislike this whole typedesc business and would rather remove it from the language |
06:14:54 | adoniscik | maybe I should use an enumeration then |
06:15:04 | adoniscik | make a correspondence between the enums and the types |
06:15:10 | Araq | what's your use case? |
06:15:47 | adoniscik | set the data structure's type; default to float but let the user specify float32 or float64 if he wants |
06:16:17 | adoniscik | t: typedesc to be used in seq[t] |
06:16:31 | adoniscik | t: typedesc = float |
06:18:40 | Araq | ah yeah. well I wouldn't do that |
06:18:59 | Araq | I would simply give no default type, it's usually not necessary: |
06:19:28 | Araq | var v: Foo[float] # only need to write it down here |
06:19:40 | Araq | bar(v) # gets inferred here anyway |
06:25:31 | adoniscik | If a C function whose header nimrod can find fails with "execution of an external program failed", does that mean the linker can't find the library? |
06:26:36 | Araq | yes, pretty much |
06:28:34 | * | boydgreenfield quit (Quit: boydgreenfield) |
06:33:26 | superfunc | has anyone had experience with the nimrod support in pygmentize? |
06:38:34 | adoniscik | when calling C libraries, I'm passing an additional LOC1 parameter that's coming from nowhere, and the compiler complains because it does not match the number of parameters in the C header file. |
06:39:21 | adoniscik | it's tacked on after the last argument |
06:40:16 | * | boydgreenfield joined #nimrod |
06:41:18 | Araq | that sounds like you use "openArray" where it makes no sense |
06:42:31 | adoniscik | there is an array. I first tried openarray, then array, then ptr array. |
06:42:45 | adoniscik | what's the right way to pass one to C? |
06:45:04 | * | gkoller_ joined #nimrod |
06:45:13 | * | gkoller_ quit (Client Quit) |
06:45:27 | * | gkoller joined #nimrod |
06:49:14 | Araq | ptr array |
06:49:55 | adoniscik | and addr array for the parameter, right? |
06:49:57 | Araq | superfunc: not sure but if that's the syntax highlighter written in python, it's quite broken |
06:50:05 | Araq | adoniscik: right |
06:50:55 | superfunc | Yeah, too tired to look into fixing it. |
06:52:22 | adoniscik | well, it doesn't work: http://pastebin.com/9L1AFqeX |
06:52:22 | * | dom96_ios joined #nimrod |
06:52:48 | dom96_ios | superfunc: thats what github uses so it should work quite well |
06:53:19 | def- | superfunc: i used it in my slides as well, it mostly worked, except with templates and stuff like 12'u32 |
06:54:13 | dom96_ios | There is a wiki page with known issues. Add to it if you found some. At some point I or someone else will send a PR to pygments fixing them. |
06:54:37 | Araq | and 5 years after that the github guys might have applied it |
06:55:34 | dom96_ios | Yes, why update something that works? |
06:55:42 | * | superfunc quit (Ping timeout: 260 seconds) |
06:56:26 | Araq | adoniscik: well C cannot possibly return an array[I, cdouble] |
06:56:54 | Araq | so nimrod transforms that somewhat |
06:57:07 | Araq | it helps if you don't lie at the compiler |
06:57:18 | adoniscik | I see. I set the return to ptr array and it changed |
06:57:48 | * | dom96_ios quit (Quit: dom96_ios) |
06:57:53 | adoniscik | the compiler's message could be more clear; I didn't know how to interpret it |
07:02:52 | * | gkoller quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
07:04:04 | Araq | unfortunately it cannot read your mind yet |
07:11:27 | fowl | going to migrate nake over to something like this https://gist.github.com/fowlmouth/c142a2089a4a77a85b04 |
07:20:36 | * | gkoller joined #nimrod |
07:20:38 | Araq | fowl: er ... why? |
07:25:04 | * | gkoller quit (Client Quit) |
07:27:11 | * | kunev joined #nimrod |
07:29:50 | fowl | plugin background service adware integration |
07:32:50 | Araq | sounds good |
07:33:07 | Araq | make sure it's webscale |
08:06:58 | * | gkoller joined #nimrod |
08:07:47 | * | BitPuffin quit (Ping timeout: 245 seconds) |
08:20:37 | adoniscik | is there a good reason why the option "clib" adds the path to the parameter? when I pass libfoo I want ld to search the library path, but it doesn't because nimrod passes -l/absolute-path/libfoo |
08:22:34 | * | gkoller quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
08:24:58 | * | bjz_ joined #nimrod |
08:34:40 | * | BitPuffin joined #nimrod |
08:38:01 | * | gkoller joined #nimrod |
08:39:26 | adoniscik | I can get around it by using -l:"-lfoo" but that just seems dumb. Just checking to make sure people are aware of it? |
08:40:59 | adoniscik | I'm guessing it's due to the processPath in https://github.com/Araq/Nimrod/blob/b119dc2f3b35f6fb84bc9661ea0fbbd006fba433/compiler/commands.nim#L442 |
08:41:13 | adoniscik | #L445 rather |
08:42:04 | * | bjz_ quit (Ping timeout: 250 seconds) |
08:43:03 | * | malthe joined #nimrod |
08:43:03 | * | boydgreenfield quit (Quit: boydgreenfield) |
09:00:35 | * | gkoller quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
09:01:22 | * | goobles joined #nimrod |
09:13:38 | * | SillyPanda quit (Quit: Textual IRC Client: www.textualapp.com) |
09:14:05 | * | kshlm joined #nimrod |
09:18:14 | * | darkfusion joined #nimrod |
09:20:58 | * | adoniscik quit (Ping timeout: 250 seconds) |
09:33:32 | * | ics quit (Ping timeout: 250 seconds) |
09:36:51 | * | ics joined #nimrod |
09:37:12 | Skrylar | Araq: but does the webscale background integration allow me to synergize my big data? |
10:20:35 | * | bjz_ joined #nimrod |
10:34:06 | * | bjz_ quit (Ping timeout: 260 seconds) |
11:12:04 | * | gkoller joined #nimrod |
11:26:06 | * | foodoo joined #nimrod |
11:45:14 | * | gkoller quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
11:49:34 | * | xenagi joined #nimrod |
11:49:35 | * | foodoo quit (Quit: leaving) |
11:51:34 | * | gkoller joined #nimrod |
12:03:44 | * | johnsoft joined #nimrod |
12:04:48 | * | gkoller quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
12:08:11 | * | mwbrown joined #nimrod |
12:15:15 | * | kshlm quit (Ping timeout: 272 seconds) |
12:16:51 | * | flaviu joined #nimrod |
12:23:38 | * | xenagi quit (Quit: Leaving) |
12:34:03 | * | untitaker quit (Ping timeout: 240 seconds) |
12:39:40 | * | untitaker joined #nimrod |
12:42:32 | * | darkf quit (Quit: Leaving) |
13:14:24 | * | mwbrown quit (Ping timeout: 260 seconds) |
13:44:05 | * | ARCADIVS joined #nimrod |
13:52:47 | * | gkoller joined #nimrod |
13:59:48 | * | gkoller quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
14:05:45 | * | malthe quit (Remote host closed the connection) |
14:08:16 | * | gkoller joined #nimrod |
14:10:41 | * | ics quit (Ping timeout: 256 seconds) |
14:12:24 | * | ics joined #nimrod |
14:25:39 | * | gkoller quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
14:44:54 | * | Demos joined #nimrod |
14:55:16 | * | boydgreenfield joined #nimrod |
15:24:37 | * | nande joined #nimrod |
15:32:49 | * | gkoller joined #nimrod |
15:35:40 | * | gkoller quit (Read error: Connection reset by peer) |
15:45:41 | * | Johz joined #nimrod |
15:47:41 | Johz | Heya, is there an obvious way to turn an AST representation into the expression it represents? |
15:48:36 | * | boydgreenfield quit (Quit: boydgreenfield) |
16:00:05 | * | boydgreenfield joined #nimrod |
16:05:26 | * | nande quit (Read error: Connection reset by peer) |
16:06:45 | Demos | Alpha release of VisualNimrod! I have been personally using it for a while and it seems stable enough, but expect some issues |
16:07:29 | OrionPK | woo! |
16:07:42 | OrionPK | way to go Demos :) |
16:08:51 | Demos | again expect bugs |
16:08:59 | Demos | but I wanted to get a prepackaged release out there |
16:09:01 | OrionPK | Error 106 Could not copy the file "E:\Development\GitHub\VisualNimrod\NimrodVS\ItemTemplates\NimrodItems.zip" because it was not found. NimrodVS |
16:09:26 | Demos | just download the VSIX |
16:11:07 | Demos | I should have deleted those install targets from the vsixmanifest before tagging but I did not. See the templates will auto-install when you build the project but they will not be copied into the vsix, so I need to add those items to package the whole vsix as standalone but then remove them or there will be duplicates of each template |
16:15:03 | Demos | I am interested to make sure that the packaged vsix actually works on other people's computers/VS versions |
16:19:41 | * | io2 joined #nimrod |
16:21:56 | Demos | OrionPK, did you get eaten by a guru? |
16:23:36 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
16:24:44 | OrionPK | sorry, working |
16:25:00 | Demos | ah |
16:26:07 | * | boydgreenfield quit (Quit: boydgreenfield) |
16:26:34 | OrionPK | yeah you need to clean up that github :p |
16:26:39 | OrionPK | so where's the vsix? |
16:26:46 | Demos | on the releases page |
16:29:48 | * | SillyPanda joined #nimrod |
16:30:37 | * | kunev quit (Ping timeout: 245 seconds) |
16:34:43 | * | ics joined #nimrod |
16:39:35 | OrionPK | ah duh |
16:40:27 | * | Johz quit (Quit: Page closed) |
16:42:47 | OrionPK | now we just need the inline debugging ;) |
16:43:00 | OrionPK | integrated ratehr |
16:43:18 | flaviu | compile the code with --linedir:on --debuginfo |
16:43:32 | flaviu | Works for me with GDB |
16:45:55 | Demos | oh yeah, I should add that to the next release |
16:46:17 | Demos | in the mean time you can edit the .nimproj file to do it |
16:49:22 | * | silven_ joined #nimrod |
16:50:07 | * | silven quit (Ping timeout: 272 seconds) |
16:50:11 | Demos | I compile stuff by just executeing what is essentially a batch script |
17:10:26 | * | adoniscik joined #nimrod |
17:11:27 | * | q66 joined #nimrod |
17:11:29 | * | Trustable joined #nimrod |
17:12:52 | dom96 | Demos: How do I uninstall an old version of vsix? |
17:13:17 | dom96 | nvm |
17:13:28 | Demos | tools->extensions and updates -> nimrodVS -> uninstall |
17:14:43 | dom96 | cool it works :O |
17:15:21 | * | kunev joined #nimrod |
17:15:23 | dom96 | completion doesn't |
17:15:43 | dom96 | Also syntax highlighting is not the best |
17:15:47 | * | kunev quit (Remote host closed the connection) |
17:15:52 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
17:15:57 | dom96 | "<span color=\"#CC0E0E\"> *</span>" it thinks there is a comment in there |
17:19:45 | Demos | make an issue! And completion should... sometimes |
17:20:07 | Demos | you need to pull it up with ctrl-space |
17:21:26 | * | boydgreenfield joined #nimrod |
17:22:24 | * | bjz quit (Ping timeout: 250 seconds) |
17:22:30 | Araq | writeStackTrace() is very nice for debugging |
17:22:47 | Araq | I wonder if we need a "debug Nimrod the hard way" tutorial |
17:24:46 | * | bjz joined #nimrod |
17:26:20 | Demos | I found the stack traces I am getting from gcc/windbg/lldb/VSDebugger to be pretty decent |
17:29:53 | * | ARCADIVS quit (Quit: WeeChat 0.4.3) |
17:31:13 | * | Fx00F joined #nimrod |
17:38:08 | * | brson joined #nimrod |
17:40:09 | * | kunev joined #nimrod |
17:42:03 | * | Jesin quit (Ping timeout: 240 seconds) |
17:42:15 | * | Johz joined #nimrod |
17:45:38 | Araq | Johz: make a macro return this AST |
17:45:56 | Johz | That's what I thought. |
17:46:22 | Johz | In that case, how do you pass a variable containing AST into a macro? :P |
17:47:19 | Johz | I suspect I'm doing something really really stupid somewhere, but I can't quite figure out what it is. |
17:48:01 | * | Dispatch joined #nimrod |
17:48:35 | Johz | I'm making a config macro that returns a type and a set of procs for that type that return instances of that type given filenames and config strings etc. |
17:48:49 | Dispatch | Hi, I have a question about callbacks |
17:49:09 | Dispatch | if the callback is defined as this: WindowSizeFun* = proc (window: Window; width: cint; height: cint) {.cdecl.} |
17:49:40 | Dispatch | and my implementation is this: proc Resize(window: glfw.Window; width, height: cint) {.cdecl.} = |
17:50:17 | Johz | I can scan through the macro easily, and I now have a collection of objects that reference specific parts of the original macro, still in AST form. |
17:50:25 | Dispatch | wait I mean like this: proc Resize(window: glfw.Window; width, height: cint) {.procvar.} = |
17:50:36 | Dispatch | I get a type mismatch |
17:50:59 | Dispatch | got (Window, proc (Window, cint, cint) | proc (ptr T, Natural): ptr T{.inline.}) |
17:51:02 | Johz | I can construct the AST for a type quite easily for this, but the proc contains a lot of logic, and so writing out the AST manually for it and plugging everything in isn't working. |
17:51:22 | Dispatch | expected: glfw3.SetWindowSizeCallback(window: Window, cbfun: WindowSizeFun): WindowSizeFun |
17:52:00 | Dispatch | Can anyone tell me what I am doing wroing? |
17:53:25 | fowl | Dispatch, your callback probably lacks {.cdecl.} or something |
17:53:57 | Dispatch | tried that, but then I get: Error: value of type 'WindowSizeFun' has to be discarded |
17:54:08 | Dispatch | so how do I discard the WIndowSizeFun in this line: |
17:54:15 | Dispatch | glfw.SetWindowSizeCallback(window, Resize) |
17:54:31 | fowl | which wrapper are you using |
17:54:31 | Dispatch | oh |
17:54:39 | Dispatch | putting it in front of that line |
17:54:52 | Dispatch | this is rafaelvasco/nimrod-glfw wrapper |
17:55:09 | Dispatch | So I got it! |
17:55:22 | Dispatch | looks like I needed a hint and a rubber duck |
17:55:27 | Dispatch | thanks1 |
17:56:25 | fowl | Dispatch, nimrod is stricter than c, he should have made those functions {.discardable.} so you dont have to do that |
17:57:06 | dom96 | there is also https://github.com/EXetoC/nim-glfw/ which has a high-level binding too |
17:57:15 | Dispatch | ah, ok |
17:57:26 | Dispatch | I'll check the one from Exetoc |
17:58:34 | * | sam__ joined #nimrod |
17:58:44 | * | sam__ quit (Client Quit) |
17:59:26 | Dispatch | Hmm, I like the rafael one better, I like low level. |
18:00:41 | dom96 | exetoc's one provides both |
18:00:46 | fowl | there is a low level wrapper in there too |
18:01:28 | fowl | glfw/wrapper |
18:02:31 | * | boydgreenfield quit (Quit: boydgreenfield) |
18:06:03 | Dispatch | oh, yeah I see. |
18:06:18 | Dispatch | got it working now, but I'll keep it in mind. Useful for comparing. |
18:07:35 | Araq | Johz: please gist some example |
18:17:42 | * | boydgreenfield joined #nimrod |
18:22:53 | * | vendethiel joined #nimrod |
18:23:49 | * | Ven joined #nimrod |
18:28:06 | Johz | Araq, https://gist.github.com/MrJohz/2052e42d000f8ce624fb |
18:30:45 | Araq | Johz: I'm not sure I get your problem but you can't access PowConfig and fromFile in another macro as a macro cannot access the global symbol table |
18:31:28 | Araq | your 'config' macro needs to generate everything since that has the original key/value pairs |
18:31:45 | Johz | That's been my plan so far. |
18:33:32 | Johz | I've been trying to generate a proc that operates on a "generic" config key, and then using the AST methods copy out the parts of the tree that deal with the "generic" key, and replace them with the idents etc specific to the node I'm looking at. |
18:33:48 | Johz | **specific to the config keys that have been declared |
18:38:47 | Araq | well I have no idea what your problem is |
18:39:53 | * | nande joined #nimrod |
18:43:21 | Johz | Araq, this might make more sense: Here's the annotated code I've got so far, and the errors it produces: https://gist.github.com/MrJohz/2052e42d000f8ce624fb |
18:44:42 | Johz | My guess is that the copied version of attempt1.nim:line 36, which mixes a Sym and an Ident, isn't allowed. |
18:45:29 | Johz | If that's right, is there a way to create a Symbol? I can't imagine that being the case, because I can't necessarily point my symbol at the thing it's representing. |
18:45:50 | Johz | Alternatively, is there a version of the quote() proc that doesn't convert everything to symbols? |
18:47:15 | Araq | quote is unusable |
18:47:24 | Araq | and indeed your problem is that you generate symbols |
18:48:47 | Johz | In that case, how would you recommend I create the AST I need? |
18:48:58 | Araq | parseStmt |
18:49:16 | goobles | is visual nim a visual studio thing |
18:49:27 | Johz | Ah, using strings instead. |
18:49:34 | Johz | I'll give that a go. Thanks! |
18:52:59 | * | adoniscik quit (Ping timeout: 272 seconds) |
19:01:22 | * | kunev quit (Ping timeout: 260 seconds) |
19:06:09 | * | Hat_and_Cloak joined #nimrod |
19:06:11 | * | goobles quit (Quit: Page closed) |
19:06:25 | * | goobles joined #nimrod |
19:06:53 | goobles | demos: is visual nimrod available somewhere |
19:07:17 | * | mwbrown joined #nimrod |
19:07:36 | dom96 | goobles: https://github.com/barcharcraz/VisualNimrod |
19:07:41 | Demos | yes. But again it is an early alpha and has some bugs. It is released for people to test out. |
19:08:33 | goobles | cool thanks |
19:11:31 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
19:12:06 | * | kunev joined #nimrod |
19:16:15 | * | Dispatch quit (Quit: Page closed) |
19:17:03 | * | kunev quit (Ping timeout: 272 seconds) |
19:20:08 | * | Ven joined #nimrod |
19:32:39 | * | kunev joined #nimrod |
19:32:51 | dom96 | Anybody good with opengl here? |
19:33:02 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
19:33:20 | goobles | glvertex3f |
19:33:44 | * | Ven joined #nimrod |
19:34:10 | goobles | i mostly use d3d these days, but used to know opengl pretty well, what u trying to do |
19:34:28 | dom96 | Just trying to draw a triangle lol |
19:34:33 | * | dom96 is a total noob |
19:34:46 | goobles | oh, in immediate mode? |
19:35:02 | dom96 | what's that? |
19:35:10 | flaviu | dom96: glvertex3f is deprecated |
19:35:12 | dom96 | and how do I know if i'm in it? |
19:35:22 | dom96 | flaviu: what? |
19:35:24 | goobles | immediate mode is classical GL where you use glvertex3f etc |
19:35:27 | flaviu | If you're not using point buffers, you're in immediate mode |
19:35:45 | goobles | yes it is deprecated, I don't think it is available on mobile GL etc |
19:35:46 | dom96 | I'm following this: http://open.gl/drawing |
19:36:30 | dom96 | https://gist.github.com/dom96/9fc5a01cabd321721f07 |
19:36:32 | dom96 | My code |
19:36:32 | flaviu | dom96: That doesn't mention vertex3f at all |
19:36:59 | dom96 | I guess I am doing something silly, but I can't find what. |
19:37:00 | flaviu | Oh, goobles was suggesting something |
19:37:01 | goobles | that is not using immediate mode |
19:37:12 | dom96 | Could be a mis-translation from C to Nimrod. |
19:37:39 | flaviu | Sorry, can't help you. I only know the immediate mode API :P |
19:37:49 | flaviu | I've never used anything over GL 1.1 |
19:37:53 | dom96 | lol |
19:38:04 | dom96 | well at least i'm not learning deprecated stuff |
19:38:14 | * | enurlyx joined #nimrod |
19:38:27 | goobles | what does it do when u run it |
19:38:34 | goobles | does the window appear? |
19:39:15 | dom96 | yeah, nothing shows up just black in the window though |
19:39:50 | dom96 | glGetError returns 0 too |
19:39:54 | goobles | gl has some shitty API for getting error messages |
19:39:55 | goobles | ah ok |
19:40:05 | goobles | you gotta call it after each API call |
19:40:10 | goobles | it is a retarded system |
19:40:37 | dom96 | argh |
19:40:40 | dom96 | That's what I suspected |
19:41:08 | dom96 | But hrm |
19:41:22 | Araq | no, it's not retarded, it's good old C style where 90% of everything is boilerplate |
19:41:48 | dom96 | the opengl wrapper does that for me doesn't it? |
19:41:56 | Demos | dom96, yeah |
19:42:12 | dom96 | Well then... gl hates me |
19:42:16 | Demos | also you can use the KHR_debug extension to have openGL call a function pointers when there is an error |
19:42:27 | Demos | you should do this because glGetError can be quite slow |
19:43:12 | dom96 | Demos: Does the wrapper do that already? |
19:43:16 | Demos | if I have a set[someEnum] where card(set) == 1 can I cast it to the enum and find out what that one element is? |
19:43:26 | Demos | dom96, I don't think so as it is not core |
19:43:34 | Demos | the wrapper does call glGetError though |
19:43:59 | goobles | what is this 0'i32 you are passing to glVertexAttribPointer |
19:46:29 | Demos | dom96, that offset param of glVertexAttribPtr should probably be sizeof(float32 * 2) |
19:46:43 | * | eigenlicht quit (Ping timeout: 256 seconds) |
19:47:45 | Araq | Demos: no, but you can cast it to int and do a "find lowest bit set" via some intrinsic |
19:47:55 | * | eigenlicht joined #nimrod |
19:48:27 | Demos | and then cast that to an enum |
19:48:36 | dom96 | Demos: Nope, that doesn't fix it. |
19:48:46 | goobles | delete opengl |
19:48:56 | dom96 | goobles: the stride I believe? |
19:49:02 | goobles | yes |
19:53:37 | goobles | ur stride should be what demos said, I don't know what 0'i32 even means |
19:53:45 | goobles | some nimrod thing;0 |
19:54:03 | goobles | but GL is finiky beast with horrible error reporting |
19:54:18 | Fx00F | goobles: 32 bits int |
19:54:42 | goobles | ya i can figure what i32 means |
19:54:48 | goobles | but what is 0' |
19:55:01 | Araq | 0 |
19:55:17 | dom96 | goobles: it doesn't help |
19:55:39 | Demos | let me poke at it in nsight |
19:56:17 | dom96 | Demos: thanks |
19:59:42 | Demos | vertices is of type array[float, 6].... |
20:00:00 | Demos | in vec2 is a vector of two 32-bit floats |
20:02:58 | Demos | nimrod's float is 64-bit |
20:05:16 | goobles | triangle no happy cause u sliced his floats |
20:05:30 | dom96 | yep that's it |
20:05:46 | * | kunev quit (Ping timeout: 250 seconds) |
20:07:28 | dom96 | stupid C and its void pointers |
20:08:18 | dom96 | odd thing is why it doesn't give an error |
20:08:33 | goobles | cause it doesn't see any error |
20:08:38 | goobles | it just see some memory |
20:08:45 | goobles | and draws a triangle.. off in the boondocks |
20:08:59 | dom96 | ahh of course |
20:09:06 | Demos | if it were to give you an error than it would have to actually be a whole game engine |
20:09:14 | dom96 | thanks for the help |
20:10:00 | dom96 | yeah, I guess OpenGL is very flexible. |
20:13:11 | * | BitPuffin quit (Ping timeout: 264 seconds) |
20:17:17 | * | Hat_and_Cloak quit (Quit: Leaving) |
20:21:47 | * | BitPuffin joined #nimrod |
20:32:13 | * | Trustable quit (Quit: Leaving) |
20:41:16 | * | Jehan_ joined #nimrod |
21:06:21 | * | vbtt joined #nimrod |
21:07:28 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
21:08:30 | * | Matthias247 joined #nimrod |
21:11:00 | * | Jesin joined #nimrod |
21:15:37 | * | Fr4n quit (Ping timeout: 245 seconds) |
21:17:22 | * | vbtt quit (Ping timeout: 250 seconds) |
21:28:53 | * | Fr4n joined #nimrod |
21:42:05 | * | brson quit (Ping timeout: 272 seconds) |
21:43:15 | * | Johz quit (Quit: Leaving) |
21:48:06 | * | brson joined #nimrod |
21:52:52 | * | eigenlicht quit (Ping timeout: 260 seconds) |
21:55:24 | * | eigenlicht joined #nimrod |
21:57:44 | * | Matthias247 quit (Quit: Matthias247) |
21:58:32 | Varriount__ | Meep. |
21:58:36 | * | Varriount__ is now known as Varriount |
21:59:05 | flaviu | Beep. |
21:59:56 | * | Varriount flavors flaviu with some flavenoids |
22:00:05 | OrionPK | ahoy varriount |
22:02:17 | Varriount | Hm. Are there any PR's needing review that don't affect the compiler? |
22:02:37 | Varriount | Or the system module |
22:02:43 | flaviu | https://github.com/jfhg/Nimrod/commit/26ba9e6d3286adddaff0d3c13e91d973f443bf51 looks pretty harmless |
22:02:57 | flaviu | Well, #1407 |
22:03:20 | Varriount | *pulls request* *breaks reality* |
22:03:36 | NimBot | Araq/Nimrod devel 26ba9e6 jfhg [+0 ±1 -0]: fix build on DragonFly BSD and FreeBSD |
22:03:36 | NimBot | Araq/Nimrod devel 835f700 Varriount [+0 ±1 -0]: Merge pull request #1407 from jfhg/devel... 2 more lines |
22:04:04 | * | Matthias247 joined #nimrod |
22:04:37 | * | superfunc joined #nimrod |
22:05:20 | flaviu | I'm not sure why #1289 hasn't been merged yet either, no comments there |
22:05:33 | * | enurlyx left #nimrod (#nimrod) |
22:05:46 | NimBot | Araq/Nimrod devel bd8f5c8 Billingsly Wetherfordshire [+0 ±1 -0]: json.== handles nil now |
22:05:46 | NimBot | Araq/Nimrod devel 99aaefe Varriount [+0 ±1 -0]: Merge pull request #1289 from fowlmouth/patch-5... 2 more lines |
22:06:13 | * | Fx00F quit (Quit: leaving) |
22:06:20 | Araq | because I wanted to review it |
22:06:29 | Araq | and never did |
22:06:31 | NimBot | Araq/Nimrod revert-1289-patch-5 f67b9bc Varriount [+0 ±1 -0]: Revert "json.== handles nil now" |
22:08:04 | Varriount | Erm, that revert commit didn't actually happen - it's just a waiting PR at the moment. |
22:09:32 | Varriount | Anyone see anything wrong with https://github.com/Araq/Nimrod/pull/1313 ? |
22:10:12 | * | superfunc quit (Ping timeout: 255 seconds) |
22:10:36 | flaviu | I would make https://github.com/flyx/Nimrod/commit/f59ca2736dac0e544c11aaca431408931d3e21de#diff-ace6742e546f8141a187185d1e3346c3R338 consistant |
22:11:04 | flaviu | `else: result = equalsImpl()` |
22:18:03 | OrionPK | Demos, clicking 'x' out of the add new item dialog throws an error.. sometimes |
22:18:24 | Demos | OrionPK, I have not seen that error |
22:18:42 | NimBot | Araq/Nimrod devel f59ca27 Felix Krause [+0 ±2 -0]: Fixed `==` for PTables, added test. |
22:18:42 | NimBot | Araq/Nimrod devel e5acd9d Clay Sweetser [+0 ±2 -0]: Merge branch 'ptables_fix' of git://github.com/flyx/Nimrod into flyx-ptables_fix |
22:18:42 | NimBot | Araq/Nimrod devel 18003ff Clay Sweetser [+0 ±1 -0]: Added stylistic consistancy. |
22:18:42 | NimBot | Araq/Nimrod devel ba394e6 Varriount [+0 ±2 -0]: Merge pull request #1410 from Varriount/flyx-ptables_fix... 2 more lines |
22:18:44 | Demos | I have seen errors when I close the whole IDE though |
22:18:55 | OrionPK | "Invalid capability expression at positiion 29" |
22:19:02 | OrionPK | it only happens the first time you open the dialog though, for me |
22:24:09 | * | boydgreenfield quit (Quit: boydgreenfield) |
22:28:00 | * | BitPuffin quit (Ping timeout: 250 seconds) |
22:31:26 | OrionPK | Demos the ctrl e+c (comment shortcut) adds //'s |
22:32:19 | Demos | you should open issues for these things on github so I remember them |
22:32:28 | Demos | I will do it but still |
22:33:48 | OrionPK | sure |
22:33:56 | OrionPK | I will do that from now on |
22:35:50 | Demos | the number of bugs caught by my "is quaternion normalized" asserts is massive |
22:35:53 | Demos | totally huge |
22:35:57 | Demos | could feed a village |
22:38:19 | Varriount | WHat are you guys testing? |
22:43:31 | flaviu | Varriount: Visual studio nimrod plugin |
22:43:41 | * | Fx00F joined #nimrod |
22:47:11 | * | darkf joined #nimrod |
22:47:59 | * | Fr4n quit (Ping timeout: 264 seconds) |
23:00:13 | * | Fr4n joined #nimrod |
23:02:25 | * | Fr4n quit (Client Quit) |
23:03:04 | * | BitPuffin joined #nimrod |
23:07:10 | * | Matthias247 quit (Read error: Connection reset by peer) |
23:45:59 | * | Fr4n joined #nimrod |
23:52:44 | * | Jesin quit (Quit: Leaving) |