| 00:00:36 | * | PrincessKaDenza is now known as comex |
| 00:15:27 | reactormonk | proc len*[T](x: seq[T]): int {.magic: "LengthSeq", noSideEffect.} # invalid with Error: pragmas are only allowed in the header of a proc |
| 00:15:30 | reactormonk | I copy/pasted it around |
| 00:35:55 | fowl | you can only have pragma in the header |
| 01:15:54 | * | q66 quit (Remote host closed the connection) |
| 04:07:06 | * | OrionPK quit (Quit: Leaving) |
| 04:57:02 | reactormonk | meh, I'll do some more forward declares |
| 05:43:43 | * | amarsahinovic joined #nimrod |
| 05:44:24 | * | amarsahinovic left #nimrod (#nimrod) |
| 07:27:28 | * | Araq_ joined #nimrod |
| 07:34:12 | * | amarsahinovic joined #nimrod |
| 07:35:44 | * | Araq_ quit (Read error: Operation timed out) |
| 07:36:45 | * | Araq_ joined #nimrod |
| 07:50:04 | * | ARCADIVS quit (Quit: WeeChat 0.3.8) |
| 08:22:46 | * | Araq_ quit (Read error: Operation timed out) |
| 08:25:04 | * | Araq_ joined #nimrod |
| 08:35:22 | * | q66 joined #nimrod |
| 08:52:42 | * | Araq_ quit (Read error: Connection timed out) |
| 08:54:47 | * | Araq_ joined #nimrod |
| 10:18:19 | * | Araq_ quit (Quit: ChatZilla 0.9.90 [Firefox 19.0.2/20130307023931]) |
| 10:56:55 | * | Trix[a]r_za is now known as Trixar_za |
| 10:58:09 | * | amarsahinovic left #nimrod (#nimrod) |
| 11:34:12 | * | Araq_ joined #nimrod |
| 11:44:17 | * | Araq_ quit (Quit: ChatZilla 0.9.90 [Firefox 19.0.2/20130307023931]) |
| 13:08:28 | * | Araq_ joined #nimrod |
| 13:11:30 | * | Araq_ quit (Client Quit) |
| 13:19:11 | * | Trixar_za is now known as Trix[a]r_za |
| 14:18:03 | * | comex quit (Ping timeout: 249 seconds) |
| 14:18:04 | * | comex` joined #nimrod |
| 14:18:29 | * | comex` is now known as comex |
| 14:42:13 | * | XAMPP quit (Ping timeout: 256 seconds) |
| 16:36:43 | reactormonk | Araq, what if I need sequences at compile-time? |
| 16:52:58 | NimBot | Araq/Nimrod 850d567 Zahary Karadjov [+0 ±1 -0]: fixes iterating over enums |
| 16:52:58 | NimBot | Araq/Nimrod b4245e6 Zahary Karadjov [+1 ±2 -0]: some steps to improve the type mismatches with the new... 2 more lines |
| 17:46:16 | * | Endy joined #nimrod |
| 18:12:40 | * | zahary joined #nimrod |
| 18:16:10 | zahary | Araq, I think you shouldn't have reverted my commits, but instead just update the master ref to point before them |
| 18:17:06 | Araq | I dunno, I planned to push a hot fix for dom96 |
| 18:17:28 | Araq | unfortunately it turned out to be some hard bug, so I'm still working on it |
| 18:18:16 | reactormonk | Araq, is it possible to use a different stdlib at compile and runtime? ... |
| 18:18:59 | Araq | reactormonk: no ... and your question about the 'seq' at compile time is a good one |
| 18:19:11 | Araq | I'm thinking about it |
| 18:19:31 | reactormonk | Araq, just gimme a 'thinking on it' and I'll keep quiet ;-) |
| 18:19:39 | Araq | in the worst case you have to implement 'newSeq' and make it raise a runtime error |
| 18:19:58 | reactormonk | good, I'll go with that then |
| 18:20:10 | reactormonk | wait, what if I call it during compiletime? Also gives me a runtime error |
| 18:20:43 | Araq | it shouldn't since it's a magic that has its own implementation in the evaluation engine |
| 18:24:05 | Araq | zahary: btw tfieldindex seems to be broken on your branch |
| 18:24:13 | reactormonk | can I determine if code is run during compile or runtime? |
| 18:24:58 | Araq | 'when defined(nimrodvm)' iirc |
| 18:25:19 | Araq | would be "at compile time" |
| 18:26:34 | * | Endy quit (Ping timeout: 246 seconds) |
| 18:33:35 | Araq | thinking about it ... I think that means we already have a runtime system and compiletime system module |
| 18:34:00 | zahary | araq, btw what is the purpose of the compileTime pragma in tfieldindex? I think that according to the spec, this should disable the multiple instantiation behavior of the typedesc param and turn the proc into a macro-like function that takes type symbols |
| 18:34:40 | zahary | i.e. a function that is compiled only once (not generic) |
| 18:35:11 | zahary | in such a function, it should be illegal to use the typedesc parameter in this manner: |
| 18:35:11 | zahary | var x: T |
| 18:35:25 | Araq | well 'typedesc' is ambigious and we need to fix it |
| 18:35:45 | Araq | maybe we need typedesc[T] vs. typedesc |
| 18:36:45 | Araq | your change to bound it for the unification process broke template t(a, b: typedesc) |
| 18:36:48 | zahary | ambiguos in the sense (a compile time proc taking a type symbol or generic proc that need a needs a new instantiation for each type?) |
| 18:37:17 | Araq | for a start it's not obvious what to do for the unification |
| 18:37:21 | zahary | I'll fix the bind once problem by other means - it's not related to the discussion here |
| 18:37:29 | Araq | we have expr vs T for ordinary expressions |
| 18:37:35 | Araq | we only have typedesc for types |
| 18:37:54 | Araq | I dunno how you can fix it |
| 18:38:00 | Araq | we need both? |
| 18:41:10 | Araq | compileTime is necessary to enforce evaluation at compile time; I'm not sure it should influence the genericness of a proc |
| 18:41:36 | Araq | though I can see that it often leads to intuitive behaviour |
| 18:42:55 | zahary | compileTime prevents run-time code generation - does it also mean "implied static calls"? |
| 18:43:07 | Araq | yes |
| 18:43:20 | zahary | I think may "macro-like" treatment also makes sense |
| 18:43:29 | Araq | --implicitStatic:on|off affects this as well |
| 18:43:37 | Araq | as I said, your treatment makes sense too |
| 18:44:02 | Araq | I think --implicitStatic:on needs to be active all the time and the switch gone |
| 18:44:26 | Araq | then 'indexOf' can get rid of 'compileTime' |
| 18:45:55 | dom96 | The Nimrod website will be down at 1am GMT+1 tomorrow, this includes, nimbuild (NimBot) and the forum. Just FYI. |
| 18:46:23 | zahary | I'm for implicitStatic:on too - this is how my hypolang was supposed to work |
| 18:47:47 | zahary | and with few more additions. var x = somethingConst() becomes const x = … |
| 18:47:47 | zahary | if somethingConst() becomes when …, etc |
| 18:48:14 | Araq | 'if' has different scoping rules than 'when' |
| 18:48:38 | Araq | and I don't like 'var' turning into 'const' either |
| 18:49:21 | zahary | well, this will be natural consequence of implementing dependent typing |
| 18:49:47 | zahary | so, it's likely to effectively happen anyway |
| 18:49:59 | Araq | var x = "" # turn into a 'const'? |
| 18:50:10 | Araq | I guess that's not what you mean |
| 18:51:15 | Araq | and what has dependent typing to do with it? |
| 18:51:29 | zahary | the compiler now knows the exact value of x, and this can affect any ifs that follow. |
| 18:51:29 | zahary | if x.len > 0 |
| 18:52:47 | Araq | yeah got it |
| 18:52:50 | dom96 | Isn't 'var' by definition mutable? is this only in the case where the compiler can prove that no modifications of the var take place? |
| 18:53:04 | Araq | dom96: yes |
| 18:54:08 | zahary | I think I missed what you object about - var turing into const and this affecting mutability down the line |
| 18:54:16 | zahary | I don't want that too |
| 18:54:44 | Araq | yeah I got it now |
| 18:55:31 | Araq | implicitStatic:on is the natural thing to do but there were lots of edge cases |
| 18:56:06 | Araq | for instance the compiler would happily evaluate newString(3000) resulting in bad code generation |
| 18:56:43 | Araq | also it mustn't evaluate 'echo' at compile time just because it can |
| 18:57:45 | Araq | I'm not sure I got rid of all of them |
| 18:58:49 | zahary | yeah sure, bloat in the final image due to things like newString(3000) and improperly unrolled loops was may main concern too |
| 19:01:00 | reactormonk | Araq, btw, all those interdependencies in the system module :-( |
| 19:05:59 | Araq | reactormonk: btw you should replace the error messages by an error code enum |
| 19:06:11 | Araq | and document that |
| 19:06:19 | reactormonk | Araq, error messages? |
| 19:06:45 | Araq | in the EBase get rid of the message field, make it an enum instead |
| 19:07:10 | reactormonk | and what should go in there? |
| 19:08:13 | Araq | TErrorCode = enum errOverflow, errInvalidIndex etc. |
| 19:09:50 | zahary | how is the user supposed to add his own error codes? from a library? |
| 19:13:00 | zahary | regarding the typedesc binding rules… here is a heretical idea breaking backwards compatibility, but ultimately more consistent with the current state: |
| 19:13:00 | zahary | what if foo[T: typedesc]() stops being equivalent to foo[T]() and becomes a way to introduce named bindOnce typedesc parameter |
| 19:13:00 | zahary | so if I want to define the function typesEqual, I would do typesEqual[T: typedesc)(a, b: T) |
| 19:15:05 | zahary | otherwise, I can solve the problem with named bindOnce aliases (to be used with implicitly generic procs) |
| 19:15:18 | zahary | just like I can say type T1 = expr , T2 = expr |
| 19:15:34 | zahary | and then write functions like |
| 19:15:34 | zahary | proc foo(a: T1, b: T2, c: T1) |
| 19:15:57 | zahary | equivalent to foo[T, U](a: T, b: U, c: T) |
| 19:16:15 | zahary | the same can be done with TT1 = typedesc, TT2 = typedesc ... |
| 19:19:16 | Araq | zahary: the context is a microcontroller with 16KB of RAM, I don't think user defined exception messages are necessary; errOther suffices |
| 19:19:42 | zahary | ah, I though you are discussing a general change, sorry |
| 19:19:46 | reactormonk | Araq, 2KB of RAM, 16KB of flash |
| 19:20:20 | reactormonk | maybe it was 32 |
| 19:20:30 | Araq | my mindstorm has 32KB of RAM and a display :P |
| 19:21:18 | Araq | and supports 'exit' I think |
| 19:22:45 | Araq | zahary: I'm not sure I like it, too much magic |
| 19:23:02 | dom96 | zahary: if foo[T: typedesc] stops being equivalent to foo[T]() then the T with no constraints will no longer be free to accept everything as its definition currently suggests I think. Wouldn't that become a bit confusing? |
| 19:23:10 | zahary | there was a classic story of a legendary programmer that was reusing the assembly instructions in his code as constants in other parts of code :) |
| 19:23:38 | Araq | what if we support proc distinctTypes(a: distinct typedesc, b: distinct typedesc) ? meh ... I don't like that either |
| 19:23:49 | zahary | which part don;t you like? the new treatment of typedesc in generic params or the implicit generics trick? |
| 19:23:57 | reactormonk | zahary, couldn't the compiler optimize that? |
| 19:25:10 | dom96 | wait, I don't get it. Why is foo[T: typedesc] currently equivalent to foo[T]? In the former case T is constrained to always be a "typedesc" i.e. a type, in the latter it's unconstrained so it should accept anything. |
| 19:25:34 | Araq | dom96: where "anything" means "any value" |
| 19:25:42 | Araq | not "some type" |
| 19:25:49 | zahary | dom96, I don't suggest anything to change about foo[T]() # it's just that we currently have this redundant foo[T: typedesc] that nobody would use out of lazyness and it just wastes "banddith" (the ability of the language to express different things) |
| 19:26:36 | Araq | well the idea was that you can have foo[T: typedesc, X: expr] |
| 19:26:42 | zahary | bandwidth |
| 19:26:50 | Araq | and back then there was no ';' |
| 19:26:55 | fowl | why is unittest.nim not listed on http://build.nimrod-code.org/docs/lib.html and there's no doc page for it (i tried ./unittest.html) |
| 19:27:05 | zahary | yes, that's why I said "more consistent with the current state" |
| 19:27:06 | Araq | so you couldn't write foo[T; X: expr] |
| 19:27:28 | Araq | alright I agree then |
| 19:27:41 | Araq | make T: typedesc consistent |
| 19:27:53 | Araq | fowl: because I forgot it |
| 19:28:26 | fowl | i thought i saw an example use for it too but cant find it now |
| 19:30:31 | dom96 | Araq: I'm still confused. If ``T`` means "any value" then how can ``T: typedesc`` possibly be equivalent to it? When from what I understand ``T: typedesc`` means "any type"? |
| 19:31:10 | zahary | see, even dom96 is confused about the current meaning :P |
| 19:32:20 | Araq | dom96: well that's what it means, consider [T: int|float] |
| 19:32:43 | Araq | that doesn't mean that T is a meta type either |
| 19:32:48 | Araq | it means it can be int or float |
| 19:33:14 | dom96 | It means that T can either be an int value or a float value. |
| 19:33:15 | fowl | i'd like for this to work: proc foo[T] (ty: typdesc[T]; val: T); foo int, 1 |
| 19:33:35 | * | amarsahinovic joined #nimrod |
| 19:33:48 | Araq | fowl: yeah that a good point |
| 19:33:54 | fowl | since i get errors like that: got (typedesc[int], int literal(32)) but expected one of: |
| 19:34:10 | dom96 | Am I confused about what 'typedesc' means? |
| 19:34:19 | Araq | dom96: we all are |
| 19:34:35 | dom96 | that helps lol |
| 19:35:57 | dom96 | From what I understand: when zahary said "what if foo[T: typedesc]() stops being equivalent to foo[T]()" he implied that it currently is equivalent. So let me try to get a grip on this with some examples: |
| 19:36:07 | Araq | zahary: btw is there a language with these meta types parameters to learn from? |
| 19:36:21 | dom96 | proc foo[T: typedesc](bar: T) = nil |
| 19:36:27 | zahary | I think the fowl example would work in the same way foo(ty: typedesc[Ordinal], val: Ordinal) would work now |
| 19:36:34 | dom96 | foo(string) # fine |
| 19:36:40 | dom96 | foo("value") # fine |
| 19:36:50 | dom96 | and same goes if the definition of foo is: |
| 19:36:59 | dom96 | proc foo[T](bar: T) = nil ? |
| 19:37:06 | zahary | Araq, I'm not aware of another language going this far. some of the tricks are present in XL for example |
| 19:38:00 | fowl | dom96: know of an example unittest use? |
| 19:38:05 | Araq | dom96: no, foo(string) is not be fine with the current compiler |
| 19:39:00 | Araq | fowl: examples/tunit.nim |
| 19:39:23 | dom96 | fowl: Look for tests beginning with 'u' in the tests/ dir |
| 19:39:48 | fowl | thx |
| 19:40:21 | dom96 | Araq: In which case is it not fine? |
| 19:40:29 | dom96 | in which foo definition? |
| 19:40:44 | Araq | in both |
| 19:40:58 | Araq | currently foo[T: typedesc] and foo[T] are the same |
| 19:41:15 | dom96 | oh, I get you now hah |
| 19:41:19 | Araq | and foo(x: typedesc) would accept the type |
| 19:42:53 | dom96 | Isn't this just a matter of the compiler performing a replace of "T" in the param list with "typedesc"? :P |
| 19:44:05 | Araq | there is no "just replace it" when it comes to types; why do you think generics take a decade to get into stable state? |
| 19:44:45 | dom96 | True. In any case that's what I thought of, which is the source of my confusion I guess. |
| 19:44:50 | dom96 | Thanks for clearing it up. |
| 19:50:02 | dom96 | reactormonk: HIB accepts BTC now :O |
| 19:55:41 | * | fowl quit () |
| 19:56:53 | * | fowl joined #nimrod |
| 20:00:35 | reactormonk | dom96, HIB? |
| 20:01:03 | dom96 | reactormonk: humble indie bundle |
| 20:16:23 | * | gradha joined #nimrod |
| 20:17:35 | reactormonk | oh |
| 20:21:17 | gradha | dom96: logs still don't use the meta in the html header, will you fix that during tomorrow's outage or are the logs using now a reverted version due to the recent bugs? |
| 20:22:30 | Araq | the latter I think |
| 20:25:07 | * | amarsahinovic left #nimrod (#nimrod) |
| 20:25:21 | dom96 | indeed what Araq said |
| 20:30:03 | gradha | it seems that Claro's revival won't happen soon http://forum.nimrod-code.org/t/159 |
| 20:35:31 | gradha | fowl: your bindings aren't listed yet at http://sfml-dev.org/download/bindings.php |
| 20:36:08 | fowl | true |
| 20:36:10 | fowl | ill email him |
| 20:43:44 | fowl | i should notify sdl too |
| 21:14:02 | * | ba joined #nimrod |
| 21:14:07 | * | ba left #nimrod (#nimrod) |
| 21:15:43 | * | toolmaker joined #nimrod |
| 21:16:28 | * | zahary quit (Quit: Leaving.) |
| 21:16:50 | gradha | welcome toolmaker |
| 21:17:16 | toolmaker | Thanks gradha! |
| 21:18:09 | gradha | Araq is around so you can nag him with feature requests |
| 21:20:06 | gradha | I know coroutines are the rage, but what about https://en.wikipedia.org/wiki/Grand_Central_Dispatch as a lightweight alternative to threads? |
| 21:21:41 | toolmaker | I was looking for coroutines more as a form of continuations…but looking at the macro system, do you think it would be a feasible alternative to rewrite a function into smaller chuncks or something like that? |
| 21:22:57 | toolmaker | Like you know, on every yield keyword, the macro would split a argument function into two or more smaller functions that would then be wrapped as an iterator or something? |
| 21:23:16 | Araq | toolmaker: check out http://nimrod-code.org/manual.html#first-class-iterators |
| 21:23:58 | Araq | as I said, we have an 'async' macro in the works that translates a proc into a "closure iterator" (I really should have picked a different name I think) |
| 21:24:09 | gradha | I know pretty much nothing about coroutines, can't find any use case for my programming to exercise them |
| 21:24:44 | Araq | this is way easier then splitting things into smaller functions |
| 21:25:20 | Araq | bbl |
| 21:26:49 | gradha | toolmaker: what do you like to use coroutines for? |
| 21:29:05 | toolmaker | I have a bunch of communicating virtual machines that pass around instructions to each other.. I use continuations to 'pause' the execution of an instruction mid way if the vm wants to further talk to a different vm to complete the currently executing instruction. |
| 21:31:32 | gradha | that's the kind of situation I would model with state machines, running manually their "loop", I guess coroutines are nicer to write |
| 21:32:10 | toolmaker | Regarding the soft-realtime gc, this includes it's usage for audio applications too right? I mean, not that I'd use mallocs in a real-time |
| 21:32:22 | toolmaker | … thread but still |
| 21:33:56 | toolmaker | Is completely bypassing the GC a viable alternatives (I'm really getting ahead of myself here because I've only read the manual at this point, have yet to play with the compiler yet)? |
| 21:34:34 | toolmaker | I really like the code transformation possibilities of nimroid however, I sort of need continuations.. |
| 21:34:56 | gradha | IIRC Araq mentioned it being possible to disable the GC and handle memory manually |
| 21:36:09 | fowl | toolmaker, whats wrong with 1st class iterators isnt that a coroutine |
| 21:38:54 | Araq | fowl: it's a very limited coroutine as it doesn't capture the stack; it apparent when you consider that 'yield' can only occur in the iterator itself and not in some helper function |
| 21:39:00 | toolmaker | I'm not sure I understand you see… if I remember correctly, the iterator construct is just like a macro that transforms the 'iterator' into a loop thingy … I am not sure if it saves the stack and register values and that I can use it properly without putting it a forloop |
| 21:40:04 | toolmaker | plus what Araq said.. I'd like to wrap the yield statement into different functions so that the user of my api doesn't actually realise that they're inside a coroutine... |
| 21:40:28 | fowl | o |
| 21:40:50 | toolmaker | Araq: Is what I'm saying correct? |
| 21:40:52 | fowl | i dont use stacks or threads because i'm too much of a maverick |
| 21:41:45 | toolmaker | you use stack all right :) that's whenever you make function calls or just allocate things by doing something like int a = 1; and such.. |
| 21:42:07 | fowl | i meant coros not stacks >_. |
| 21:42:25 | toolmaker | oh.haha.. |
| 21:43:16 | Araq | toolmaker: a closure iterator keeps its state in a closure and so can be used for a simple tasking system |
| 21:43:59 | Araq | and you can get quite far since you can have a 'yield' in a template |
| 21:44:38 | Araq | the compiler doesn't transform it into a loop but into a state machine |
| 21:44:41 | toolmaker | hmm…right |
| 21:45:11 | toolmaker | So, what's the difference really? |
| 21:45:27 | Araq | it captures locals but not the call stack |
| 21:45:56 | Araq | so you can't use recursion |
| 21:46:20 | toolmaker | I'll have a look at this…I think I could make it work…recursion isn't a problem in my case; i could avoid it |
| 21:46:56 | Araq | it is good enough for C#'s async stuff |
| 21:47:10 | toolmaker | Araq: how exactly does memory allocations work? Can I specify the initial size of the memory arena or does the allocations happen incrementally? |
| 21:47:23 | Araq | as C# uses essentially the same implementation |
| 21:48:43 | Araq | toolmaker: happens incrementally |
| 21:50:28 | toolmaker | Araq: I see..I'll have a look at the docs once again and play with it more.. |
| 21:51:19 | fowl | https://github.com/fowlmouth/asteroids :> |
| 21:51:21 | toolmaker | The part of the world I'm from, it's 3:35 in the morning right now. Where are you guys located? When can I find you guys in the room normally? |
| 21:51:48 | Araq | it's 23:55 here |
| 21:52:06 | fowl | 2:50 PM here |
| 21:52:29 | toolmaker | 2:50 PM or 2:50 AM fowl? |
| 21:52:30 | gradha | it's tuesday here |
| 21:52:49 | fowl | PM |
| 21:52:58 | * | OrionPK joined #nimrod |
| 21:53:13 | toolmaker | CA.. i see... |
| 21:53:33 | dom96 | toolmaker: interesting time zone, where are you from if you don't mind me asking? |
| 21:53:45 | toolmaker | Nepal |
| 21:53:58 | toolmaker | far far away huuh? |
| 21:53:59 | toolmaker | :) |
| 21:54:23 | toolmaker | I'll be back when I have questions.. gotta go sleep .. see you guys later |
| 21:54:36 | Araq | same here |
| 21:55:09 | * | toolmaker left #nimrod (#nimrod) |
| 21:58:43 | * | gradha quit (Quit: bbl, have youtube videos to watch) |
| 22:04:14 | * | fowl quit (Ping timeout: 245 seconds) |
| 22:46:43 | * | fowl joined #nimrod |
| 22:47:00 | * | Trix[a]r_za is now known as Trixar_za |
| 22:50:46 | fowl | anybody know whats going on here https://gist.github.com/fowlmouth/5666749#file-ubbtree-nim-L40 |
| 22:53:06 | fowl | doesnt make sense |
| 22:53:34 | fowl | bb(0,0,1,1) == bb(0,0,1,1) is true |
| 22:58:44 | dom96 | argh, now I regret I didn't "schedule" this downtime an hour earlier |
| 22:58:48 | * | dom96 yawns |
| 23:06:11 | fowl | dom96, what are you working on? |
| 23:06:42 | dom96 | currently nothing why? |
| 23:07:47 | fowl | want to take a look at my issue?(: |
| 23:10:34 | dom96 | sure, i'm probably too tired to be of much help though |
| 23:11:53 | dom96 | So the compiler generates incorrect C code? |
| 23:12:39 | fowl | no i dunno about that error im going to submit an issue for it |
| 23:12:48 | fowl | the problem is one.bb isnt matching bb(0,0,1,1) |
| 23:12:55 | fowl | `==` i should say |
| 23:14:16 | dom96 | interesting, perhaps try finding the definition of `==` for tuples, maybe you can figure out what's happening by adding some echo's in there |
| 23:15:53 | fowl | above that an assert bb(0,1,2,3) == bb(0,1,2,3) passes |
| 23:17:02 | dom96 | what's the definition of 'bb'? |
| 23:17:39 | fowl | proc bb[T: TNumber] (x,y,w,h: T): TBB = (x.float,y.float,w.float,h.float) |
| 23:18:42 | fowl | hm i changed it to let test_one = one.bb and get a cgen error |
| 23:19:07 | dom96 | maybe the macro is doing something funky |
| 23:21:19 | fowl | yea these macros are super complicated |
| 23:21:26 | fowl | unittest.nim |
| 23:21:42 | fowl | the use of macros, templates, overriding consts |
| 23:21:55 | dom96 | if you're getting cgen errors then perhaps the compiler is generating incorrect C code even when gcc compiles it. |
| 23:22:26 | fowl | yea |
| 23:22:30 | dom96 | Does it still happen if you don't use the macro? |
| 23:24:36 | fowl | yep same err |
| 23:25:31 | fowl | test_one = one_84047.Field0; |
| 23:25:57 | dom96 | can you create an example without the dependency on your libs? |
| 23:26:12 | fowl | weird its using field0 it should be field1 |
| 23:29:38 | fowl | it works if i access it with [1] |
| 23:31:10 | dom96 | sounds like a pretty serious bug |
| 23:35:26 | fowl | and now its not happening -_- |
| 23:37:49 | fowl | ok so it only happens if i use the (a: x, b: y) syntax to declare them |
| 23:43:59 | fowl | thanks dom96 |
| 23:44:30 | dom96 | no worries |